KR20030074982A - Software fault tolerance method by software - Google Patents

Abstract

PURPOSE: A software fault tolerance method is provided to embody a software fault tolerance, using a primary/backup redundancy method. CONSTITUTION: When a call is generated in a system, an application(102) requests the assignment of an index ID to a CID(Call Instance Data) table(104) of a primary(100)(111). The CID table(104) generates a CID object to store information about the call(113). The CID table(104) retrieves an idle index ID to be assigned to the call from a free ID pool(115). The CID table(104) assigns the retrieved idle index ID to the call, and transmits the call to the application(102)(117). The application(102) stores call process association data in the corresponding CID object of the CID table(104)(119,121). The CID table(104) transmits the CID object to a CID table(154) of a backup(150)(123). The CID table(154) generates an application session, using information stored in the CID object(125), and transmits the application session to an application(152) of the backup(150)(127). The application(152) requests call process data to the CID table(154)(129). The application(152) processes the call, using the call process data received from the CID table(154). If a release request with respect to the call is generated from the application(102) of the primary(100)(131), the CID table(104) deletes the CID object with respect to the corresponding call(133), and returns the index ID assigned in the call to the free ID pool(135). The CID table(104) notifies the release with respect to the call to the CID table(154) of the backup(150)(137). The CID table(154) deletes the CID object with respect to the corresponding call(139), and requests the application(152) to release the application session corresponding to the call(141).

Description

SOFTWARE FAULT TOLERANCE METHOD BY SOFTWARE}

The present invention relates to a method for implementing software fault tolerance on a system, and more particularly to a method for implementing software fault tolerance using a primary / backup redundancy technique.

The fault tolerance (Fault Tolerance, fault tolerance, fault tolerance) means that even if a part of the system fails, the processing can continue without affecting the whole, and the fault can be repaired and replaced in the meantime. (Or "fault tolerance" may mean "the degree to which all, parts or programs of the system can withstand the effects of internal failures"). Conventionally, in order to implement a fault tolerance system, a hardware fault tolerance technique is used to detect an error in a central processing unit (CPU) or a peripheral element through multiplexing of hardware, in particular, multiplexing of processing elements. It has been used to detect and mask. The fault masking is a method of combining a functional unit required to perform a function in a system with a functional unit that operates the same as the functional unit, so that an error due to the occurrence of the failure does not appear on the output when the failure occurs. Means. On the other hand, when using the above-mentioned hardware fault tolerance technique has the following advantages. First, since the recovery time is shorter than that of the software duplication processing method, the overall system down time is shortened. Second, since the fault detection and recovery process is hardware dependent, the complexity of the software is reduced. In addition, since the complexity of the software can be reduced as described above, the software development cost is relatively reduced when using the hardware fault tolerance technique.

On the other hand, there are the following disadvantages when using the hardware fault tolerance technique. First, there is always a need for hardware that meets the requirements. In most cases, specific hardware is required, so development and production costs are very high. Second, in-house development can lead to more than a few years of use technology trends. Third, it may not be easy to adapt to changes in hardware technology.

Accordingly, an object of the present invention to solve the above problems is to provide a method for implementing a structurally flexible system fault tolerance.

Another object of the present invention is to provide a method for implementing a system fault tolerance that can be easily adapted to changes in hardware technology.

It is another object of the present invention to provide a method for reducing the cost of implementing a system fault tolerance.

In order to achieve the above objects, the present invention operates as a primary / backup, wherein the primary and backup store the information on the pre-identity pool, the checkpointed ID pool, the equalization ID pool, and the generated objects, respectively. The first process of requesting the index ID for the call to the primary when a system is generated in order to implement fault tolerance by the system having the D table, and the requested primary receives information about the generated call. A second step of creating a ID object and storing the ID object in the ID table; and a third step of searching for a free ID pool and assigning an index ID present in the free ID pool to the call; Delete an ID from the free ID pool and store it in the checkpointed ID pool. And a fifth process of storing information on the generated call in the ID object stored in the ID table, and transmitting the ID object for the ID stored in the checkpointed ID pool as a backup. A sixth step; storing the received ID object in a backup ID table; and deleting the ID object stored in the primary ID table when the call is released. And an eighth process of returning the index ID assigned to the free ID pool and a ninth process of requesting the release of the call as a backup.

1 is a diagram illustrating a CID index ID management algorithm between primary and backup

2 is a flowchart illustrating a CID transfer operation between a primary and a backup.

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings. In the following description of the reference numerals to the components of the drawings, it should be noted that the same reference numerals as much as possible even if displayed on different drawings.

The present invention is directed to a method for implementing fault tolerance of a system in software. Software fault tolerance on commodity hardware is a way to implement fault tolerance of the system at a lower cost than using hardware.In addition to improving performance and reliability of commodity hardware such as workstations, many faults have been developed due to the development of distributed technologies. That's how it's being applied to tolerance systems. The software fault tolerance scheme is structurally more flexible than the hardware fault tolerance scheme and can be easily adapted to changes in hardware technology because it uses general-purpose hardware. In the present invention described below, a primary / backup redundancy scheme is particularly used to implement software fault tolerance.

When using the primary / backup method, Call Instance Data (hereinafter referred to as “CID”) is used for call processing between the primary and backup. The CID is used to effectively perform the synchronization process between the primary and the backup.

Referring to FIG. 1 to be described later, the primary 100 and the backup 150 are free ID pools 110 and 160, and checkpointed ID pools 120 and 170, and equalization. Three ID pools for managing index IDs of an ID pool (EqualizationIdPool) 130 and 180 are provided.

First, the CID collection and delivery process in the primary 100 is as follows. When a call is generated, each application 102 in charge of call processing of the primary 100 selects CIDs to be delivered to the backup 150 and stores them in a CID table managing them. At this time, the CID information is stored in each CID object managed by the CID table designated by each ID using the unique ID assigned from the CID table as an index. When all CIDs for the call are stored in the CID table, the CID table forwards the CID and index Id information to the backup 150. This is an individual data transfer method per call. On the other hand, if only the primary 100 is being driven, only the storage process is performed in the CID table of the primary 100 without transmitting the CID to the backup 150. An example in which only the primary 100 is driven may be a state in which a failure occurs in the backup 150 and is not recovered. When the backup 150 is newly driven in a situation where call processing is continuously performed, the primary 100 immediately transmits each CID for all calls that have been generated to the backup 150 immediately to the primary 100. And the synchronization process between the backup 150 is performed. This is a batch data delivery method. On the other hand, the above two data transfer methods may be performed together while performing the synchronization process.

Meanwhile, the backup 150 should perform a process for restoring all CIDs received from the primary 100 in the CID table in the same structure as in the primary 100. That is, the backup 150 stores the CID for the call in the CID table using the index Id information received together with the CID received from the primary 100. In addition, the backup 150 performs the restoration process in the same structure as the primary 100 using mapping information between call processing application sessions among the CID information. The restored application sessions obtain their data from the CID and use it to perform call processing in the backup 150.

Meanwhile, the CIDs are deleted when the call ends. The following describes the deletion process of the CID. When call processing ends, CID information stored in the CID table must also be released. If a call release request comes into the primary 100, the system deletes the CID for the call in the primary 100 and notifies the backup 150 of the call through the index Id of the call to backup 150. The CID inside is also deleted. Table 1 below shows an example of the ID table, which is a mapping table between the index ID and the CID object.

Index Id CID Object Pointer 0 CID1Object One CID2Object 2 NULL ....... ....... Max_IndexId_Cntr NULL

Hereinafter, the fault tolerance method of the present invention made through the index ID and the ID objects will be described with reference to the accompanying drawings.

1 is a diagram illustrating a CID index ID management algorithm between a primary and a backup.

As described above, the primary 100 and the backup 150 each include a free ID pool 110, 160, a checkpointed ID pool 120, 170, and an equalization ID pool. 130 and 180 are provided. On the other hand, the primary 100 and the backup 150 can change the role of each other depending on whether a failure of the system, the equalizationIdPool (130) 180 is operated only when operating as a primary.

The CID object where the call processing data is stored is managed by the free Index Id allocated by the freeIdPool 110 of the primary 100, and the Index Id is managed by the three Id Pools. do. That is, initially, the CID Table that allocates any idle Ids stored in the freeIdPool 110 creates a CID Object mapped to the Index Id, and transfers the Index Id information and the CID Object Pointer information to the application session.

The Application Session stores the allocated Index Id information, stores the call processing related data in the CID Object using the CID Object Pointer, and when all the call processing related data are stored, the CID Table transmits it to the backup 150. At this time, the Index Id information is stored in the checkpointedIdPool 120 again.

The backup 150 receiving the CID Object from the primary 100 adds and deletes the corresponding Index Id in its freeIdPool 160 and checkpointedIdPool 170, respectively. In addition, it creates a CID object for storing CID information and stores the CID. In addition, the same application sessions as the primary 100 are generated using mapping information between call processing application sessions among the CID information. The generated applications request call processing related data from the CID table and store it in their own area.

2 is a flowchart illustrating a CID transfer operation between a primary and a backup.

Hereinafter, the operation of the present invention will be described in detail with reference to FIGS. 1 and 2.

When a call occurs in the system, the application 102 requests an index ID allocation to the CID table 104 of the primary 100 in step 111. In step 113, the CID table 104 generates a CID object to store information about the call. In step 115, the CID table 104 searches for an idle index ID to be allocated to the call in the freeIdPool 110. In step 117, the CID table 104 assigns the retrieved idle index ID to the call and transmits the retrieved idle index ID to the application 102. In steps 119 and 121, the application 102 stores call processing related data generated for the call in a corresponding CID object of the CID table 104. In step 123, the CID table 104 transfers the CID object to the CID table 154 of the backup 150. The CID table 154 generates an application session using the information stored in the CID object and transfers it to the application 152 of the backup 150. Application 152 requests call processing data for the call to the CID table 154. Using the call processing data received from the CID table 154, the application 152 may perform the processes for the call.

On the other hand, when a release request for the call occurs from the primary application 102 (step 131), the CID table 104 deletes the CID object for the corresponding call in step 133, and in step 135 The index ID assigned to the call is returned to freeIdPool 110. That is, the index ID is added to the IDs of the freeIdPool 110 again and is managed as an idle ID. In step 137, the CID table 104 notifies the CID table 154 of the backup 150 of the release of the call. Accordingly, the CID table 154 deletes the CID object for the call in step 139 and requests the application 152 to release the application session corresponding to the call in step 141.

Through the above-described process, the synchronization process between the primary 100 and the backup 150 is completed. Through this, even when an error occurs in one of the primary 100 and the backup 150, the other side is storing data even when an error occurs and recovers it again. The data currently being processed is transferred immediately from the side to the side of the failure, making the recovery process abominable.

As described above, the present invention using software can implement a fault tolerance system at a lower cost than using hardware. In addition, the present invention is structurally flexible compared to hardware fault tolerance, and can be easily adapted to changes in hardware technology.

Claims (2)

Fault tolerance in a system operating as primary / backup, wherein the primary and backup each have a pre-ID pool, a checkpointed ID pool, an equalization ID pool, and a seed table that stores information about the objects that occur. In the method, Requesting an index ID for the call to the primary when a call occurs in the system; A second step of the primary receiving the request generating a CD object having information on the generated call and storing the ID object in a CD table; A third step of searching for a free ID pool and assigning one index ID existing in the free ID pool to the call; A fourth process of deleting the allocated ID from the free ID pool and storing the allocated ID in the check pointed ID pool; A fifth process of storing information on the generated call in a CD object stored in the ID table; A sixth process of transferring the ID object for the ID stored in the checkpointed ID pool to a backup; A seventh process of storing the received ID object in a backup ID table; An eighth step of deleting the ID object stored in the ID table of the primary upon requesting release of the call, and returning the index ID assigned to the call to the free ID pool; And a ninth process of requesting release of the call as a backup. The method of claim 1, In the sixth process, The fault tolerance method, characterized in that when the backup does not operate normally, the ID stored in the checkpointed ID pool is stored in the equalization ID pool and transferred to the backup when the backup is normally operated.