JPH0877120A - Service fault restoration method - Google Patents

Abstract

PURPOSE: To provide the service fault restoration method which minimizes an influence upon the whole of the service due to the abnormality of object instances (OI) by realizing restoration from a fault with the OI, which is a component or the service processing function and is operated on a device on which the service processing function is mounted, as a unit. CONSTITUTION: A general object manager (GOM) is provided, and the test/ switching processing with the OI as a unit is realized by this GOM, and the abnormality (fault/degradation in performance) of OIs is quickly detected and restored; and when the operation abnormality of OIs occurs, a substitutive OI which should be substituted for the abnormal OI is selected from the other OIs or a new substitutive or is generated by GOM, and hereafter, the substitutive IO is used in the service instead of the abnormal OI to continuously present the service.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a service failure recovery method in units of object instances operating on a processing device equipped with object-oriented software, typified by communication services and calculation services.
The present invention relates to a service failure recovery method that can be used for all services that use a computer.

[0002]

2. Description of the Related Art Conventionally, service operation management is realized by fault / performance management of processing device hardware. That is, monitoring and failure recovery are performed in units of the service execution control device including many service processing functions.

FIG. 2 shows an outline of a conventional service monitoring and failure recovery method. As shown in FIG. 2 (a), each service processing node 1 is equipped with a main system service execution control device 2a that controls the execution of communication services. Corresponding to each service execution control device 2a, a backup system service execution control device 2b for backup is provided in the same service processing node 1.

Further, each service processing node 1 is provided with a monitoring device 3 for monitoring the service execution control devices 2a and 2b of the main system and the standby system. When the main system service execution control device 2a fails, the monitoring device 3 executes a switching operation to the standby system service execution control device 2b using a technique such as cold standby or hot standby.

Further, as shown in FIG. 2B, when the service execution control devices 2a and 2b of both the main system and the standby system become inoperable at the same time, the service processing node 1 provides the service. Is notified to the communication network management system 5 in the communication network management node 4.

Upon receiving the notification from the monitoring device 3 in the service processing node 1, the communication network management system 5 receives the notification from the faulty service execution control devices 2a and 2b and the service execution control device 7a in another service processing node 6. , 7b to carry out recovery measures. Here, the service processing node 6 is also provided with the monitoring device 8 for monitoring the service execution control devices 7a and 7b of the main system and the standby system as described above, and the monitoring device 8 is the service execution control device 7 of the main system.
When "a" fails, a switching operation to the standby system service execution control device 7b is executed using a technique such as cold standby or hot standby.

[0007]

However, the above-mentioned conventional service failure recovery method does not pay attention to the monitoring of individual service processing function units operating in the service execution control devices 2a, 2b, 7a, 7b. Therefore, according to this method, the service execution control devices 2a, 2b, 7a, 7
When the switching process of b is executed, other normal object instances (hereinafter referred to as OI) operating in the service execution control devices 2a, 2b, 7a, 7b are also stopped.

Therefore, the service control devices 2a, 2b,
When 7a and 7b are involved in a plurality of services, there is a problem that switching the service control devices 2a, 2b, 7a and 7b temporarily suspends services that should be continuously provided. .

An object of the present invention is to realize failure recovery in units of OI as a component of the service processing function, which operates on a device equipped with the service processing function, and to determine the degree of influence of the abnormality of the OI on the entire service. It is to provide a minimized service failure recovery method.

[0010]

In order to achieve the above-mentioned object, the present invention provides, in claim 1, object instances (OIs) operating independently of each other to exchange messages with each other and perform desired processing as a whole OI group. In a service failure recovery method for a service processing device that realizes a calculation / communication service using object-oriented software that realizes a function, a general object manager (GOM) that manages all OIs is provided, and an operation abnormality of the OI occurs. Then, the GOM selects a substitute OI to substitute for the OI from other OIs, or the substitute OI
We propose a service failure recovery method in which I is newly created, and thereafter, the substitute OI is used in the service instead of the abnormal OI to continuously provide the service.

According to a second aspect of the present invention, there is provided the service failure recovery method according to the first aspect, wherein the GOM periodically requests a test for each OI to detect an OI operation abnormality. suggest.

[0012]

According to claim 1 of the present invention, when an abnormal operation of the OI occurs, the GOM automatically selects a substitute OI as a substitute for the OI from other OIs or the substitute OI. Is automatically created, and thereafter, the substitute OI is used in the service instead of the abnormal OI, and the service is continuously provided.

Further, according to the second aspect, the GOM periodically requests a test for each OI, thereby detecting an abnormal operation of the OI.

[0014]

DESCRIPTION OF THE PREFERRED EMBODIMENTS An embodiment of the present invention will be described below with reference to the drawings. FIG. 1 is a diagram for explaining an embodiment of the present invention.
In the figure, OI _A is the OI that is advancing the process of interest, OI _C is the client OI that requests OI _A for the process, and OI _S is the OI _A that executes the process requested by OI _C. Represents the server OI requesting processing as necessary (hereinafter, these abbreviations will be used). These components are provided in the service execution control device described in the conventional example.

Further, the service in the present embodiment is provided as a result of the service processing function operating on the service execution control device or the OIs which are the constituents of the service processing control device communicating messages (requesting processing) according to a prescribed procedure. It

In this embodiment, by providing an integrated object manager (hereinafter, referred to as GOM) having the following functions, the test / switch processing is realized in units of OI, and the OI abnormality (fault / performance) is realized. It is characterized in that it enables rapid detection / recovery of (degradation) and uses a substitute OI instead of the OI in which the operation abnormality has occurred.

The functions held by the GOM are as follows: a function of identifying an OI that has caused an abnormality when a notification of an abnormality is received from the OI; a function of switching an OI that seems to be abnormal to a substitute OI; To confirm the normality of the function, each OI
Has a function to request self-test, and each OI has a possibility of the OI itself, the server OI which the OI is currently requesting processing, and the abnormality (fault / performance degradation) of the communication processing function. It has a function of detecting and notifying the GOM. Furthermore, the GOM appropriately changes the processing request relationship between OIs based on the operation normality, load, placement position, etc. of each OI. At this time, the GOM cooperates with the following managers as needed.

The managers that the GOM cooperates to deal with the abnormality of the OI are: OI generation / erasure manager (hereinafter referred to as OIR) that functions to generate / erase the OI. A processing log manager (hereinafter, referred to as PLM) that holds information about processing. An OI database (hereinafter, referred to as OIDB) that holds information on the operating state of each OI and the processing request relationship between OIs is provided.

On the other hand, as shown in FIG. 3, the OIDB holds information on the following items for each operating OI as information necessary for operating the OI and recovering from a failure. (1) OI name that can be uniquely recognized in the network (2) Execution process name (process name retained and executed by OI) (3) List of substitute (operating) OI names (Su
b OI List) This list is used to determine an OI (substitute OI) to be used after that when an abnormality occurs in the OI. (4) a list of OI name using the OI as OI _S (O
I _C List) This list shows when an OI abnormality occurs.
It is used to notify all OIs used as I _{S not} to use the abnormal OI thereafter.

(5) Usable / Unusable This indicates whether or not a request for processing can be made to the OI, and is used for state management of each OI. When an error occurs in the OI, set this item for that OI to "Not Allowed".
By doing so, the OI is assigned as a substitute for another OI by the GOM, and the dynamic coupling function (hereinafter, D
The processing request is not passed to the OI by the BF). Therefore, it is possible to prevent a service failure due to the abnormal OI thereafter.

The DBF executes a dynamic binding for determining a processing request destination when an actual message communication occurs. This function can be realized by well-known distributed processing technology (directory, trader, etc.).

The procedure for executing the dynamic connection performed by the DBF is shown below. - from each of the OI, subjected to the processing name and the object name to ask the OI _S. · Examine the items in the enable / disable of the OI _S in the OIDB. (A) ask the OI _S to perform the processing requested when usable. (B) to request a list of OI name that can run the request process to · OIDB when disabled (OI _S candidates). -A new processing request destination (OI _S ) is determined arbitrarily or based on each OI's inability level (next item). The DBF requests the OI _S for processing (the OI _C for the OI _{S at} this time is not the DBF but the OI of the processing request source).

(6) Load level This is a value determined by the number of processes per unit time requested by the OI and the maximum / minimum number of process queues within a certain measurement time. Modified and used to balance the processing load between OIs.

When the OIR deploys the OI (creates it as a process in the node), its OI name Sub OI Lis.
t, and to register the OI _C List to OIDB.

When the content of the abnormality detected by the OI is notified from the OI to the GOM, the GOM checks the content of the notification and the operation status of each OI to determine the abnormal portion and execute a recovery measure. Each OI has its own OI _S
Requested processing is to detect the fact that was not successful, it is determined that a failure has occurred in OI _S or communication processing function.

Next, a coping method for each abnormality detected by the OI will be described. <When OI detects its own abnormality> A procedure for failure recovery when the OI detects its own abnormality will be described with reference to FIGS. 4 to 6. In this case, GOM performs the following procedure.

When the OI receives the notification of the abnormality of the OI itself (FIG. 4 (0)) (SA1), the GOM executes the OI switching procedure in the following procedure.

(1) Of the information held by the OIDB, a request is made to change the usable / unavailable item regarding the OI declared as abnormal to "unavailable" (Fig. 4 (1)) (SA).
2). As a result, an OI declared as abnormal is not assigned by the GOM as a substitute for another OI, and the processing request is not passed to the OI declared as abnormal by the DBF.

(2) From the content of the notified abnormality content (error type, service type, etc.), the OI declared as abnormal is immediately deleted, or is deleted after execution of a series of OI switching processing. It is decided whether to operate it as it is (Fig. 4 (2-1)). In the case of immediate erasure, the GOM requests the OIR to execute the erasure of the OI which has been declared abnormal at this point (Fig. 4 (2-2)). The OIR requests to delete the information in the OIDB related to the OI declared as abnormal after deleting the OI declared as abnormal (Fig. 4 (2-3)) (SA
3).

After this, the GOM reports the OI declared as abnormal.
Whether or not to operate as is (SA4), and if the OI declared as abnormal is to be operated as is, OIR
Requests that the usable / unusable item related to the OI declared as abnormal among the information held by the OIDB is set to “enabled” (FIG. 4 (2-4)) (SA5).

[0031] (3) OIDB contrast, use of the abnormal-reported OI as OI _S list of all of OI name (O
I _C List) (Fig. 4 (3)) (SA6).

(4) All OIs in OI _C List
To, to stop all direct processing request for has been declared to be abnormal OI, until a subsequent instruction, an instruction to request processing through DBF in OI _S (FIG. 4 (4-1)).
The DBF also notifies the processing requester of the substitute OI name. After that, when the processing request source OI requests the processing of the same contents, until the GOM informs the official substitute OI later,
The temporary substitute OI designated by the DBF is temporarily used (FIG. 4 (4-2)) (SA7).

(5) Request the OIDB for a list of OI names that can be used as a substitute for the OI declared to be abnormal (FIG. 5 (5-1)) (SA8), and from the obtained list, The OI (substitute OI) name used as a substitute is determined (FIG. 4 (5-2)). If the load of OIs (which is periodically collected by the GOM) is unbalanced when only one substitute OI is used, a plurality of substitute OIs are set, and the substitute OIs are assigned in units of OIs in the OI _C List. Further, at this time, the deployment positional relationship between the OI and the declared OI (if no abnormality is found in the service execution control device, the OI on that device is
When a failure occurs in the node where the OI operates, the OI on the service execution control device of the node in the vicinity thereof is preferentially selected) (SA9, SA10).

(6) If there is no suitable substitute OI,
Or if the switching load of each of the substitute OI by the OI that (OI _C number of requests to execute a process to substitute OI) is increased, requests the OIR to generate a new substitute OI (FIG. 4 (6) ) (SA15).

(7) Request all OIs in OI _C List to request the substitute OIs determined in the steps up to (5) above (FIG. 4 (7-1)) (SA1)
2, SA16). At this time, each OI in the OI _C List
On the other hand, of all the information held by each OI, the name of the OI declared as abnormal is registered as the OI _S of that OI, and that name is used as a substitute OI.
Request to change the name (OI switching process). As a result, all the OIs in the OI _C List request the substitute OIs for processing instead of the abnormal OIs.

Upon receiving an approval response from the request destination OI, G
The OM further sets the O of the substitute OI in the OIDB so that the OI switching process can be executed when the substitute OI becomes abnormal.
The OIDB is requested to add the OI name that has become the client of the substitute OI to the item of I _C List (FIG. 4 (7-2)).

(8) At the time of the above (2), when the OI declared as abnormal after the switching process is designated to be deleted, the execution of the deletion of the OI declared as abnormal at this time is made to the OIR. Request (Fig. 4 (8-1)). The OIR requests to delete the information regarding the OI declared as abnormal in the OIDB after deleting the OI declared as abnormal (Fig. 4).
(8-2)) (SA14, SA18).

<When OI Detects OI _S Abnormality> Next, the procedure for failure recovery when OI detects OI _S abnormality will be described with reference to FIGS. 7 to 9. At this time, the notification that the OI _S is abnormal is sent from the OI to the GOM (Fig. 7 (0)) (SB1). At this time, however, the GOM is not only the OI _S but also the communication processing abnormality at the same time as described later. Also check at the same time. In this case, GOM performs the following procedure.

[0039] (1) OIDB Out of information held, abnormal-reported OI _S relates to the use enable / disable of the item is requested to change to "impossible" (FIG. 7 (1)) (SB
2). This prevents the GOM from assigning the OI as a substitute for another OI or passing the processing request to the OI by the DBF.

[0040] (2) OIDB contrast, the list of all of OI name using the OI _S, which has been declared to be abnormal as OI _S (O
I _C List) is requested (FIG. 7 (2)) (SB3).

(3) For all OIs in OI _C List, stop all processing requests immediately after OI _S declared as abnormal, and request processing to OI _S through DBF until further instruction is given. Instruct (Fig. 7 (3-1))
(SB4).

[0042] DBF informs also in the process requesting the substitute OI _S name. After that, when the processing requesting OI requests processing with the same content, the name of the official substitute OI _S is later changed to GO.
M Mara until informed, temporarily using a substitute OI _S provisional designated by the DBF (FIG. 7 (3-2)).

(4) At this point, the notified abnormality is
Or by abnormalities in OI _S, or whether due to failure of the communication function of the time demand / response process can not be determined. Therefore GOM, to the abnormal-reported OI _S, to request a test of its own (FIG. 7 (4)) (SB5) . Depending on the content of the reply (test result), the following procedure is executed.

(A) When the content of the response is "normal" The OI _S that has been declared abnormal is inquired whether the OI that has declared the abnormality is executing the processing requested by the OI _S (Fig. 7 (4)). -1-1)) (SB8).

(A) When the response is "execution in progress" The GOM indicates that the OI _{S that} has been declared abnormal is another OI.
(OI _SS) to inquire whether the requesting process in abnormal-reported OI _S (FIG. 7 (4-1-2)) (SB9) . The following procedure is executed according to the response content.

The OI _{S that} has been declared abnormal is another OI (O
Confirm the normality of OI _SS when requesting processing to I _SS (SB11). If OI _SS is abnormal, it is assumed that the abnormality detection function may have been reached abnormal for OI _SS of the OI _SS and OI _S, OI _S and O
Execute switching process for both I _SS (Fig. 7 (4-1-3))
(At the time of switching, the OI that was provisionally assigned until then
_S is switched to the normal substitution OI _S (FIG. 7 (4-1-
4)) (SB13). The procedure of the switching process is the same as the case of the previous embodiment, so the description will be omitted).

[0047] In addition, if OI _SS is normal, examined the process of repeatedly OI _SS is asked later, as a result,
When the abnormal OI is finally found, the switching process of the OI and the OI _C of the OI is executed (S
B12).

The OI _{S that} has been declared abnormal is another OI (O
Regarded as abnormality that can not be detected in the test when not requested to process the I _SS) is generated in the OI _S, it executes the process of switching abnormal-reported OI _S (FIG. 7 (4-1-5) ) (SB10).

(B) When the response is "non-execution", the OI that declares an abnormality is abnormal O in the PLM that is provided in each node (a plurality may be provided to improve reliability).
An inquiry is made to I _S as to whether the requested processing is registered (FIG. 7 (4-1-6)) (SB14).

Each OI (OI _S ) registers the processing name, the OI name, the OI _C name, and the processing end time in the PLM existing in the same node when the processing requested by itself is completed. (Fig. 7 (4-1-7)).

[0051] Thus, if the abnormal-reported OI _S has executed processing name to PLM is registered at the time of inquiry,
Since the processing has already been completed, it is assumed that the communication processing failure (between OI _S and abnormal reporting the OI) when responding occurs, and requests the failure recovery to the communication processing management unit (FIG. 7 (4
-1-8)) (SB15).

If the processing name executed by the OI _S declared as abnormal in the PLM at the time of inquiry is not registered, the request for the processing has not arrived at the OI _S declared as abnormal, so that when the processing is requested ( deemed to) the communication processing failure between the abnormal filing the OI and OI _S occurs, and requests the failure recovery to the communication processing management unit (Fig. 7 (4-1-9)) (SB1
6).

When it is determined that the cause of the service failure is the communication processing failure, the GOM is the temporary substitute OI until then.
_For each OI in the OI _C List that used _S , the OI cutback process is performed so that the OI _S that was originally used is used thereafter.

[0054] (2) omitted for contents of the response is "abnormal", or when there is no response to executing the switching process of the abnormal-reported OI _S (switching processing procedure is identical to the contents of the front case Yes (SB7).

By the above procedure, the abnormality is detected and recovered.

As described above, in an environment in which OIs distributed on nodes of a communication network provide services by exchanging messages with each other, when a notification of an abnormality is received from the OI, the substitute OI is notified. By providing the GOM that holds the function of performing the switching process and the function of checking the operation information of each OI, the load balance between the OIs that prevents the OIs from being abnormal and the OIs when the OIs are abnormal are provided.
Since the switching process can be realized in units, continuous provision of the entire service can be ensured more reliably than the conventional method.

Further, by providing the GOM with the function of requesting to periodically test each OI, the normality of the test function of each OI can be ensured, and therefore the reliable recovery from the failure of the OI can be ensured. realizable.

[0058]

As described above, according to claim 1 of the present invention, in an environment in which services are provided by the OIs distributed and deployed on the nodes of the communication network communicating with each other, By performing the switching process to the substitute OI when the notification of the abnormality is received, the OI
Since it is possible to realize load balance adjustment between OIs and switching processing in units of OIs when an OI error occurs, it is possible to ensure continuous provision of the entire service more reliably than conventional methods. .

Further, according to claim 2, in addition to the above effect, the GOM is provided with a function of requesting to test each OI periodically, so that the normality of the test function of each OI is ensured. Therefore, it is possible to realize a reliable failure recovery when an OI failure occurs.

[Brief description of drawings]

FIG. 1 is a diagram illustrating a configuration of an embodiment of the present invention.

FIG. 2 is a diagram for explaining a service failure recovery method by monitoring a conventional service execution control device.

FIG. 3 is a diagram illustrating information held by OIDB according to an embodiment of the present invention.

FIG. 4 is a diagram for explaining a failure recovery procedure when the OI detects its own failure in the embodiment of the present invention.

FIG. 5 is a flowchart showing a procedure of a failure recovery process using GOM when the OI detects its own failure in the embodiment of the present invention.

FIG. 6 is a flowchart showing a procedure of a failure recovery process using GOM when the OI detects its own failure in the embodiment of the present invention.

FIG. 7 is a diagram for explaining a failure recovery procedure when the OI detects a failure of the OI _S in the embodiment of the present invention.

FIG. 8 is a flowchart showing a procedure of a failure recovery process using GOM when the OI detects a failure of OI _S in the embodiment of the present invention.

FIG. 9 is a flowchart showing a procedure of a fault recovery process using GOM when the OI detects a fault of OI _S in the embodiment of the present invention.

[Explanation of symbols]

1 ... Service processing node, 2a ... Service execution control device (main system), 2b ... Service execution control device (standby system), 3
... monitoring device, 4 ... communication network management node, 5 ... communication network management system, 6 ... service processing node, 7a ... service execution control device (main system), 7b ... service execution control device (standby system), 8 ... monitoring device , OI ... object instance, GOM ... integrated object manager, OIR ... O
I generation / erasure manager, PLM ... Process log manager, OIDB ... OI database ,.

Claims (2)

[Claims] 1. A service processing device for realizing a calculation / communication service by using object-oriented software in which object instances (OIs) operating independently of each other exchange messages to realize desired processing functions as a whole OI group. In the service failure recovery method in, a comprehensive object manager (G
OM) is provided, and when an abnormal operation of the OI occurs, the GOM selects a substitute OI to substitute for the OI from other OIs or creates a new substitute OI. A service failure recovery method, characterized in that the substitute OI is used in the service instead of the incoming OI, and the service is continuously provided. 2. The service failure recovery method according to claim 1, wherein the GOM detects a malfunction of the OI by periodically requesting a test to each OI.