JPH11259326A - Hot standby system, automatic re-execution method for the same and storage medium therefor - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a hot standby system capable of speedy continuous operating through active and standby servers to be automatically operated even when any fault occurs at the active server. SOLUTION: The hot standby system is composed of the shared disk 3 for recording an operation schedule 31 of various jobs, active server 1 for automatically operating the job based on the operation schedule 31, and standby server 4 to be operated as the active server 1, based on the information recorded on the shared disk 3 when any fault occurs at the active server. Then, the active server 1 is provided with a status managing part 14 for recording the status concerning the activation conditions of job system product to perform the activation and stop of an application through the different jobs on the shared disk 3 as status information 33. The standby server 4 is provided with a job system product reactivation part 15 for reactivating the job system product through the job while referring to the status information 33 when any fault occurs at the active server 1.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a hot standby system including an active server that is automatically operated and a spare server that operates as the active server when a failure occurs in the active server. The present invention relates to a hot standby system capable of performing the above, an automatic re-execution method in the hot standby system, and a recording medium thereof.

[0002]

2. Description of the Related Art Automatic operation techniques have been introduced to automate the operation of a computer server that performs a predetermined process. In order to realize this automatic operation on a computer server, a program for monitoring the state in the server and a program for performing an operation according to an operation schedule are used. In addition, when a failure occurs in a computer server that performs automatic operation, a system configuration such as a hot standby system may be used in order to reduce the time required for recovery. Here, the “hot standby system” is an active server that operates and processes various jobs,
It is composed of a spare server, an active server and a shared disk shared by the spare server. When a failure occurs in the active server, based on information recorded on the shared disk,
The spare server operates as the active server.

FIG. 11 is a diagram showing a conventional example of the configuration of the hot standby system which is automatically operated. FIG.
1, the active server 21 and the spare server 24 have the same configuration, and the shared disk 23 is physically connected to them. Each of the active server 21 and the spare server 24 includes processing units 22 and 25, and the processing units 22 and 25
Monitoring unit 11, failure handling unit 12, schedule processing unit 1
3. Various applications 17 are executed. The functions executed by the processing units 22 and 25 will be briefly described below. The monitoring unit 11 monitors the status inside the server, and has functions such as a system monitoring and an automatic operation system.
The failure handling unit 12 detects a stopped failure of a process to be monitored or the like, and when the failure is detected, the active server 2
It has a function of switching from the first processing unit 22 to the processing unit 25 of the spare server 24. The schedule processing unit 13 starts various applications 17 in accordance with the operation schedule 31 stored in the shared disk 23 and records the history of the applications 17 as the execution history 32 on the shared disk 23. The various applications are a group of functions provided by the server to the user of the server, and are activated as jobs. Here, the monitoring unit 1
1. The schedule processing unit 13 is a functional unit required for automatic operation, and the failure handling unit 12 is a functional unit required for switching operation to the spare server 24 when a failure occurs in the active server 21. .

Next, the active server 21 and the spare server 2
4. An outline of the operation of the hot standby system including the shared disk 23 will be described with reference to FIG. In FIG. 12, the steps described on the left side (steps S11 to S1)
6) is an operation flow of the active server 21, and the steps (steps S21 to S25) described on the right side are an operation flow of the spare server 24. First, at the start of the operation of the hot standby system, the monitoring unit 11 is activated in the active server 21 and the spare server 24, and the monitoring process in the host starts (steps S11 and S21).
Next, in the active server 21 and the spare server 24,
The failure handling unit 12 is activated and starts mutual monitoring. As a result, it is possible to detect a failure occurring in the active server 21 and to automatically switch from the processing unit 22 of the active server 21 to the processing unit 25 of the spare server 24 when a failure occurs (steps S12 and S22). Next, in the active server 21, the schedule processing unit 13 is started. Then, the schedule processing unit 13 starts various applications and the like as a job according to the operation schedule 31,
Automatic operation is performed. At the same time, the history is recorded as the execution history 32 (step S14).

If any failure occurs in the active server 21 during the automatic operation (step S15), the standby server 25 detects an abnormality in the active server 21 by mutual monitoring by the failure handling units 12 in the active server 21 and the standby server 24. (Step S23). At this time, if possible, the schedule processing unit 13 is stopped in the active server 21 before switching to the spare server 24 in order to avoid developing into a failure that cannot be stopped (step S16). On the other hand, in the spare server 24, the switching process from the processing unit 22 of the active server 21 to the processing unit 25 of the spare server 24 is automatically performed by the function of the failure handling unit 12, and thereafter, the schedule processing unit 13 is activated. (Step S24). In the spare server 24, the operator refers to the execution history in the shared disk 23 in order to make the same state as the active server 21 before the occurrence of the failure. It is determined which job should be executed by referring to the execution status of the job. Then, the operator causes the job to be executed using the schedule processing unit 13 based on the determination result, and the application corresponding to the job is started (step S25). As described above, when a failure occurs in the active server 21, the server is switched to the spare server 24.

[0006]

However, in the hot standby system which is automatically operated as described above, a failure occurs in the active server, and when switching to the spare server, an operator is required to make the same state as the active server before the failure. Processing is required. In such processing by the operator, a certain operation time is required to make the same state as the active server before the occurrence of the failure. For this reason, there is a problem in that the hot standby system cannot perform rapid continuous operation from the active server to the spare server.

The present invention has been made in view of such circumstances, and even when a failure occurs in an automatically operated active server, the spare server is automatically brought into the same state as the active server before the failure occurred. It is an object of the present invention to provide a hot standby system capable of performing continuous operation quickly, an automatic re-execution method in the hot standby system, and a recording medium thereof.

[0008]

According to one aspect of the present invention, there is provided a shared disk for recording an operation schedule of various jobs, and a method for automatically controlling a job based on the operation schedule. An active server that is operated, and a hot standby system including a spare server that operates as an active server based on information recorded on the shared disk when a failure occurs in the active server, wherein the active server is A status management unit that records, as status information, a status relating to a start status of a business-related product in which start and stop of an application are performed in different jobs as status information on the shared disk, and the spare server is used when the active server fails. The business product is restarted by the job referring to the status information. Hot standby system comprising the moving parts. According to a second aspect of the present invention, in the hot standby system according to the first aspect, an execution history of a job executed according to the operation schedule by the active server is recorded on the shared disk; Determines a re-execution point in the operation schedule by referring to the execution history when a failure occurs in the active server, and determines a job based on the operation schedule from a job related to the execution point or a succeeding job of the job. And an automatic re-execution unit for re-executing the process.

The invention described in claim 3 is the same as the invention in claim 2
In the hot standby system according to (1), when the job at the re-execution point is a job related to the same batch job of terminating the application and terminating the job, the automatic re-executing unit may process the job on the active server. In the case, the job is re-executed according to the nature of the job, and if the job is being processed by a processing server other than the active server, according to the processing status and nature of the job at the processing server, The job is re-executed from the job or a succeeding job of the job. According to a fourth aspect of the present invention, in the hot standby system according to the second or third aspect, the active server and the spare server are connected to the status management unit, the business-related product restart unit, and the automatic server. 4. The hot standby system according to claim 2, further comprising a re-execution unit.

A fifth aspect of the present invention provides a shared disk for recording operation schedules of various jobs, an active server for automatically operating jobs based on the operation schedules, and a method in which a failure occurs in the active servers. An automatic re-execution method in a hot standby system including a spare server operating as an active server based on information recorded on the shared disk, wherein in the active server, an application is started and stopped by another job. Recording the status of the startup status of the system product in the shared disk, and in the spare server, referring to the status information when the active server fails, restarting the business product by a job. An automatic re-execution method in a hot standby system characterized by the following. According to a sixth aspect of the present invention, in the automatic re-execution method in the hot standby system according to the fifth aspect, the active server records an execution history of a job executed according to the operation schedule on the shared disk. The spare server determines a re-execution point in the operation schedule by referring to the execution history when a failure occurs in the active server, and determines a re-execution point in the operation schedule based on a job related to the execution point or a succeeding job of the job. It is characterized in that re-execution of a job based on a schedule is further performed.

Next, according to the present invention, a shared disk for recording the operation schedule of various jobs, an active server for automatically operating jobs based on the operation schedule, and a failure in the active server A computer-readable recording medium that records an automatic re-execution program for a hot standby system including a spare server that operates as an active server based on information recorded on the shared disk when application start and stop are performed. A status management function for the active server that records status information on the shared disk as the status of the startup status of the business product performed in a separate job,
An automatic re-execution program for causing a computer to implement a business-related product restart function for the spare server that restarts a business-related product by a job with reference to the status information when a failure occurs in the active server Is a recording medium on which is recorded. The invention described in claim 8 is:
8. A recording medium recording an automatic re-execution program in the hot standby system according to claim 7, wherein the automatic re-execution program is executed according to the operation schedule recorded on the shared disk when a failure occurs in the active server. Determine the re-execution point in the operation schedule with reference to the execution history of the job,
It is characterized by further including an automatic re-execution function for the spare server for re-executing a job based on the operation schedule from a job related to the execution point or a succeeding job of the job.

[0012]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, a hot standby system and an automatic re-execution method in the hot standby system according to one embodiment of the present invention will be described with reference to the drawings. When a failure occurs in the active server that is being automatically operated, in order for the spare server to be in the same state as the active server before the failure, appropriate execution processing of the job is required. Therefore, first, the job is sorted out based on the difference in the nature of the job and the place to be processed. Here, the processing unit defined (set) in the operation schedule is referred to as a “job”, and the processing status of the job is referred to as an “application”.

Jobs to be automatically operated are different in nature. 1) Jobs related to business products in which the application is started and stopped by another job. 2) Batches in which the end of the application and the end of the job are the same. Jobs can be broadly divided into work-related jobs. Here, jobs related to business products (hereinafter simply referred to as “business products”) include:
There are a database monitor for providing a database function, an online transaction monitor for providing a function of online request processing, and the like. These are jobs (applications) that are characterized by being activated by the execution of a start job and continuing to be activated until a stop job is executed. On the other hand, jobs related to batch work (hereinafter, simply referred to as “batch work”) include file sorting, file merger, backup, collection, distribution, and management of definition information. These are characterized in that they are started by a start job, but are terminated by the end of processing of an application which is a processing entity of the job. That is, in a normal state, the job is a job that normally terminates after the end of a predetermined process without depending on a stopped job like a business product.

A job related to a batch job is processed by a processing unit of the active server. 2b) A batch job processed by the processing unit of the active server. 2b) The job is processed by another processing server connected to the active server via a network. Batch operations. When a failure occurs in the active server when the batch operation is processed by the processing unit of the active server as in 2a), the job related to the batch operation generally ends abnormally. Therefore, when switching to the spare server, it is generally necessary to execute the job related to the batch operation again on the spare server. However, since there is a job that causes a problem when simply re-executed, it is determined whether or not to re-execute from the job, and processing is performed based on the determination result. On the other hand, when a batch job is processed by another processing server connected via a network as in 2b), the job related to the batch job is generally processed independently of the failure of the active server. Therefore, it is necessary to re-execute such a job related to a batch job from the job or its succeeding job according to the processing result of the processing server and the nature of whether or not the job can be re-executed. .

Therefore, the hot standby system of the present invention has the following features in accordance with the nature and execution place of a job. When a failure occurs in the active server, the spare server refers to the status information and automatically restarts the business-related products in batches. B) For the batch operation, the active server is activated when a failure occurs in the active server. B-1) If the batch job was processed on the active server, this batch job is re-executed on the spare server according to its nature. B-2) If the batch job was processed on a processing server other than the active server, this process is performed. Processing for re-execution is performed according to the processing status and nature of the batch operation in the server. In this case, wait for the normal end of the batch job for a certain period of time, and if the job ends normally, re-execute the following job. . In the event that a failure occurs in the automatically operated active server, the spare server can be automatically brought into the same state as the active server before the failure occurred. It should be noted that business-related products can be handled by the active server or by another processing server according to the status information of a).

Next, a hot standby system having the above functions will be described with reference to the drawings. FIG. 1 is a diagram showing one configuration example of the hot standby system of the present invention. FIG.
The hot standby system includes the active server 1, the spare server 4, and the shared disk 3. here,
The shared disk 3 is used when the active server 1 fails.
Information necessary for the spare server 4 to automatically function as the active server 1 is recorded. The active server 1 provides various functions to the user by operating and processing various jobs. The spare server 4 is a server prepared to operate as the active server 1 based on information recorded on the shared disk 3 when a failure occurs in the active server 1. Further, the active server 1 and the spare server 4 have a CPU
(Central processing unit), a processing program 2 including a control program such as an OS (Operating System), an internal memory, etc.
5 is provided. The processing units 2 and 5 execute respective functional units such as a monitoring unit 11 and a failure handling unit 12 provided as programs.

The active server 1 has a monitoring unit 1 as a functional unit.
1, a failure handling unit 12, a schedule processing unit 13, a status management unit 14, and various applications 17. The spare server 4 includes a monitoring unit 11, a failure handling unit 12,
A schedule processing unit 13, a business-related product restart unit 15, an automatic restart unit 16, and various applications 17 are provided. Here, the function of each functional unit will be described as follows. The monitoring unit 11 monitors the status in the server itself, and has functions such as a system monitoring and an automatic operation system. Here, the system monitoring function is to monitor a message from a process executed in the own server. Here, "process" refers to a program being executed. In addition, the automatic operation system function performs process restart, switching control, and the like in response to a message in cooperation with system monitoring. Troubleshooting unit 1
2 detects a stopped failure of a process to be monitored or the like, and automatically detects the processing unit 2 of the active server 1 upon detecting the failure.
From the backup server 4 to the processing unit 5. When the failure handling unit 12 is activated in the active server 1 and the standby server 4, mutual monitoring is performed between the active server 1 and the standby server 4. Then, the failure handling unit 12 of the spare server 4
When a failure such as a stop of the process to be monitored in the active server 1 is detected, a process for automatically switching from the processing unit 2 of the active server 1 to the processing unit 5 of the spare server 4 is performed. Here, as processing for switching the processing unit,
Server network address change, host name change,
There is a logical connection switching (mounting) of the shared disk 3 and the like. Note that a system including the failure handling unit 12 is generally called an HA configuration (High Availability cluster).

The schedule processing unit 13 activates various applications 17 in accordance with the job defined in the operation schedule stored in the shared disk 23, and records the execution history 32 on the shared disk 23. . This schedule processing unit 13 is called an automatic job scheduling system. The status management unit 14 records, on the shared disk, the status relating to the activation status of the business product to be managed in the active server 1 as status information 33. It should be noted that there are two types of status, "start" and "stop". The business product restart unit 15 performs processing for restarting the business product in the spare server 4 with reference to the status information 33 when a failure occurs in the active server 1. The automatic re-execution unit 16 determines a re-execution point in the operation schedule 33 with reference to the execution history 32 when a failure occurs in the active server, and causes the job to be re-executed based on the operation schedule 33. The “re-execution point” refers to a job in the operation schedule 33 at the time of occurrence of the failure. Also, the automatic re-execution unit 16
In the process of the re-execution, if the job at the re-execution point is related to a batch job and has been processed by the active server 1, the spare server 4 is selected according to the nature of the job.
When the batch job has been processed by a processing server other than the active server 1, the job is re-executed according to the processing status of the batch job in this processing server and its nature. The various applications 17 are a group of functions that the server actually provides to the user of the server, and are a group of programs for realizing the above-mentioned business products and batch business. That is, it is a group of programs that are activated to execute a job and perform the required processing.

Here, the monitoring unit 11 and the schedule processing unit 13 are functions necessary for automatic operation as described above, and the failure handling unit 12 operates when the active server 1 fails. This is a function that is required to switch operations. Then, when a failure occurs in the active server 1 on which the status management unit 14, the business product restart unit 15, and the automatic re-execution unit 16 are automatically operated, the spare server 4 quickly returns to the active server 1 before the failure. This function is necessary to automatically re-execute a job so that operation can be started in the same state. Each of the functional units denoted by reference numerals 11 to 17 is provided as a program, and the functions are realized by executing the program.

The shared disk 3 is a non-volatile recording means such as a hard disk or a magneto-optical disk, and is physically connected to the active server 1 and the spare server 4. When the active server 1 is operating normally, the shared disk 3 is logically connected to the active server 1 and the active server 1
, The logical connection of the shared disk 3 is changed to the spare server 4. The shared disk 3 records an operation schedule 31, an execution history 32, and status information 33. These specific examples will be described in detail separately. The active server 1 or the spare server 4 may be provided with a CRT (Cathode Rad) as necessary.
y Tube) and input devices such as a keyboard and a mouse.

Next, the operation of the hot standby system shown in FIG. 1 will be described in detail. FIG. 2 is a flowchart showing the operation of the hot standby system. In FIG. 2, the steps described on the left side (steps S11 to S11)
16) is an operation flow of the active server 1, and the steps (steps S21 to S27) described on the right side are an operation flow of the spare server 4. First, at the start of the operation of the hot standby system, the active server 1 and the standby server 4
In, the monitoring unit 11 is activated, and the monitoring process in the own server is started (steps S11 and S21). Next, in the active server 1 and the spare server 4, the failure handling unit 1
2 is started and mutual monitoring starts. As a result, it is possible to detect that a failure has occurred in the active server 1 and to automatically switch from the processing unit 2 of the active server 1 to the processing unit 5 of the spare server 4 due to the failure (steps S12 and S2).
2). Next, in the active server 1, the schedule processing unit 13 is started. Then, the schedule processing unit 13
Starts various applications according to the job defined in the operation schedule 31 and records the history as an execution history 32. Further, when a message indicating that the business-related product has been normally started and stopped is acquired from the execution history 32 by the system monitoring function of the monitoring unit 11 that has already been started, the status management unit 14 is started by the automatic operation function of the monitoring unit 11. Is done. The started status management unit 14 updates the status information 33 ("start" or "stop") according to the status of the status management, that is, if the product is a business product (step S14 ').

When any failure occurs in the active server 1 during automatic operation (step S15), the failure server 12 in the active server 1 and the standby server 4 detects an abnormality of the active server 1 in the standby server 4 (step S15). Step S
23). At this time, if possible, the schedule server 1 in the active server 1 before switching to the spare server 4
3 is stopped (step S16). This is to stop the automatic operation with the abnormality occurring and prevent the state from developing to a state where the operation cannot be stopped. On the other hand, in the spare server 4, the main body switching process from the active server 21 to the spare server 4 is automatically performed by the function of the failure handling unit 12. As the main body switching, the network address of the server is changed, the host name is changed, and the logical connection of the shared disk 3 is switched (mounted). Thereafter, the schedule processing unit 13 is activated (Step S24). At this point, the schedule processing unit 13 does not start processing for the job because the state of the job when the abnormality occurs in the active server 1 is unknown, and the business process product restart unit 15 and the automatic re-execution unit 16 Wait for command from. Next, in the spare server 4, the business product restart unit 15 instructs the schedule processing unit 13 to restart the business product with reference to the status information 33 (step S26). In the spare server 4, the automatic re-execution unit 16 determines the re-execution point in the operation schedule 33 with reference to the execution history 32, and instructs the schedule processing unit 13 to re-execute the job based on the operation schedule 33. . At this time, if the job at the re-execution point is a batch job, the job restart process differs depending on whether the batch job was processed by the active server 1 or another processing server (step S27). As described above, even if an abnormality occurs in the active server 1, the server is automatically switched to the spare server 4,
Automatic operation is continuously performed in the spare server 4.

Next, step S1 which is a feature of the present invention is described.
4 'and steps S26 and S27 will be described in more detail with specific examples. As a specific example described here, it is assumed that the operation schedule 31 is such that a job is scheduled as shown in FIG. 6 and a failure has occurred in the active server 1 during the automatic operation of the schedule indicated by reference numeral A or B. . Reference numeral 6 in the operation schedule 31
It is assumed that the “database monitor” and “online transaction monitor” shown in 1, 62 and 64 are jobs related to business products, and the other jobs are jobs related to batch jobs. And reference numeral 61,
Reference numeral 63 denotes a start job and a stop job for the database monitor, and reference numeral 62 denotes a start job for the online transaction monitor. The batch D 67 and the batch F 69 are jobs related to batch work requested to be processed by another processing server A, and are in parallel with the batch C 66 and the batch E 68 that are processed internally. Executed. Therefore, as shown in FIG. 10, the hot standby system 10 and the processing server A
7 is assumed to be connected via the network 6.

First, the operation of the status management unit 14 in step S14 'of FIG. 2 will be described with reference to the flowchart of FIG. When the status management unit 14 obtains a message indicating that the business product has been normally started and stopped by referring to the execution history 32 by the system monitoring function of the monitoring unit 11, it is started by the automatic operation function (step S31). . Here, the reason for starting with a normal message is that it is not necessary to reproduce the abnormal state in the spare server 4. Next, the activated status management unit 14 determines whether or not the product is a status management target, that is, a business product (step S32). here,
In the status information 33, business-related products to be managed are registered in advance, and by referring to this information, it can be determined whether or not the product is a status management target. In the status information 33, it is assumed that the statuses of all business products to be managed in the initial state are "stopped". If the status is to be managed, the status of the activation status is updated as status information 33 (step S33). This status is either "activation" or "stop", and can be determined by a message. As described above, the status information of the start or stop by the job excluding the forced termination and the abnormal termination is recorded. The contents of the status information 33 when a failure occurs in the active server 1 in the portion indicated by the reference symbol A or B in the operation schedule shown in FIG. 6 is recorded by the status management section 14 as shown in FIG. That is, the database monitor is denoted by reference numeral 6 in FIG.
The automatic operation in the step 4 causes the “stop” state, and the online transaction monitor enters the “start” state in the automatic operation 62. As described above, the status management unit 14 is provided in the active server 1 and the status information 33 is recorded on the shared disk 3 so that even if a failure occurs in the active server 1, the automatic operation status relating to the business-related product can be stored in the spare server 4 , Information to be reproduced can be left.

Next, the operation of the business product restart unit 15 in step S26 of FIG. 2 will be described with reference to the flowchart of FIG. First, the business-related product restart unit 15 initializes the number of the business-related product whose status is to be managed in the status information 33 (step S41). Next, the status of the Nth business product is searched (step S42). If the status of the N-th business product is "start", a command to start the N-th business product is issued to the schedule processing unit 13 (step S4).
3). The schedule processing unit 13 receiving this command
Performs the startup processing of the business product. Next, when the status of the N-th business product is "stop", and after the process of step S43 is completed, the variable N is used to check the status of the next business product.
Is incremented (step S44). Then, if the status check of all business-related products to be managed has been completed, the process ends, otherwise, the process returns to step S42 (step S45). As described above,
The business product restart unit 15 operates. As a specific example,
If the status information 33 is as shown in FIG.
An online transaction will be started.
Thus, in the operation schedule shown in FIG. 6, the start-up state of the business-related product up to the portion where the failure has occurred (reference numeral A or reference numeral B) can be reproduced in the spare server 4.

Next, the operation of the automatic re-execution unit 16 in step S27 of FIG. 2 will be described with reference to the flowchart of FIG. The automatic re-executing unit 16 first refers to the execution history 32 and extracts a job whose execution status is unknown (step S51). By this processing, a re-execution point is determined. For example, if a failure occurs during the automatic operation of the batch B 65 indicated by the reference symbol A in the operation schedule of FIG. 6, the execution history 32 is as shown in FIG. Accordingly, the job whose execution history is unknown in the example of FIG. 8 is batch B, and it can be seen that a failure has occurred during the automatic operation of this job. Then, this job is determined to be the re-execution point, and the processing after step S52 is performed. In FIG. 8, “の” in the execution history indicates that the process has been performed normally. As another example, if a failure occurs during the automatic operation of the batch C 66 and the batch D 67 indicated by the reference symbol B in the operation schedule of FIG. 6, the execution history 32 is as shown in FIG. Therefore,
In the example of FIG. 9, the jobs whose execution histories are unknown are batch C and batch D. It is known that a failure has occurred during the automatic operation of this job, and these jobs are determined as re-execution points. In step S51, these two jobs are extracted in order, and are respectively processed in step S52 and subsequent steps. In addition, about batch D,
Since the processing is performed by another server, the processing server information is also added. In the execution histories of FIGS. 8 and 9, for a job to be processed internally, the processing server information on which the execution processing is performed is omitted.

Next, it is determined whether the job at the re-execution point is a batch job to be executed by the active server 1, that is, whether it is a batch job to be internally processed (step S52). It should be noted that the execution history also includes information on the server on which the job is executed as described above, and the determination can be made by referring to this information. If it is a batch job to be internally processed, it is determined whether this batch job can be re-executed (step S53). The reason for determining whether or not re-execution is possible is that some applications that are started as batch operations may cause problems when re-executed. It should be noted that information relating to a job that causes a problem due to re-execution is recorded in advance on the shared disk 3, and the automatic execution unit 16 can determine whether or not a problem occurs due to re-execution of the job by referring to the information. I do. In FIG. 1, illustration of this information is omitted. If it is determined that re-execution is possible, the re-execution processing unit 16 instructs the schedule processing unit 13 to re-execute from the job extracted in step S51 (step S54). Here, the reason for re-executing from the job extracted in step S51 is that if a failure occurs during execution of a job relating to a batch job to be internally processed, the job is likely to be abnormally terminated. For example, since the batch B in FIG. 8 is a batch job to be internally processed, an execution command is issued from this job unless a problem occurs due to re-execution. Further, in the example of FIG. 9, the batch C extracted first in step S51 is a batch job to be internally processed, and therefore, execution from this job is performed unless a problem occurs due to re-execution. Done. On the other hand, if the job causes a problem due to re-execution, execution of the job and the subsequent jobs will be interrupted.

On the other hand, if the job extracted in step S51 is a job related to a batch job for which a processing request has been made to another processing server, the processing result of the batch job is checked with the processing server (step S55). ). Then, it is determined whether or not the job relating to the batch job has been completed normally by the requested processing server (step S5).
6). As described above, the processing result of the processing server is checked unless the processing server that has requested the batch operation shares resources with the active server 1 in which the failure has occurred.
This is because processing is continued without being affected by the failure. Therefore, the execution process of the requested batch job is performed independently, and the process is executed even during the switching to the spare server 4. This determination is made by making an inquiry to the processing server. If the process is abnormally terminated, or if the process is not terminated normally after a predetermined time or after a predetermined number of inquiries, it is determined that the process is not terminated normally. Note that, when the processing of the batch operation in the processing server is completed and switching to the spare server 4 is performed at the time of returning the result, the return destination of the processing result in the processing server becomes unknown. Therefore, in order to cope with such a state, it is desirable that the automatic re-execution unit 16 inquires of the requested processing server whether the processing has been completed normally, instead of waiting for the return of the result. As a specific example, in the example of FIG. 9, regarding the batch D extracted second in step S51, the determination is made in step S56 because it is a batch job requested to be processed by the processing server A. Next, step S5
If it is determined in step 6 that the job has been completed normally, the schedule processing unit 13 is instructed to re-execute from the job following the job extracted in step S51, that is, the succeeding job (step S57).

On the other hand, if it is determined in step S56 that the process has not been completed normally, the process proceeds to step S5.
It is determined whether the job extracted in 1 is re-executable (step S58). Note that this determination is made by referring to information about a job which is recorded in advance in the shared disk 3 and which causes a problem due to re-execution, similarly to the determination in step S53. If it is determined in step S58 that re-execution is possible, the re-execution from the job extracted in step S51 is instructed to the schedule processing unit 13 (step S59). On the other hand, if the job cannot be re-executed, the execution of the job and thereafter will be interrupted.

The above processing is sequentially performed on the jobs extracted as re-execution points in step S51 in step S5.
The processing after step 2 is performed, and when the extraction in step S51 ends, the processing ends. As described above, by providing the automatic re-execution unit 16, the automatic operation status up to the time when the failure occurs in the active server 1 can be reproduced in the spare server 4, and the automatic operation by the spare server 4 can be continuously performed. It becomes possible. Note that the automatic re-execution unit 16 makes the re-execution determination only for the batch work as described above. This is because, for business products, the business product restart unit 15
Has been activated and has been processed.

In the present embodiment, the hot standby system has been described as including one active server and one spare server, but the present invention is not limited to this. For example, the configuration may be such that one standby server is provided for N active servers. Further, in the present embodiment, the active server 1 has been described as including the status management unit 14 and the spare server 4 has been described as including the business product restart unit 15 and the automatic re-execution unit 16. However, the present invention is not limited to this. Instead, the active server 1 and the spare server 4 may have the same configuration. That is, both the active server 1 and the spare server 4 communicate with the status management unit 14,
It may have a business-related product restart unit 15 and an automatic restart unit 16. As a result, the two servers both have the function of the active server and the function of the standby server, and can function alternately as active servers due to the occurrence of a failure. When the active server 1 is operating normally, the spare server 4 may perform other processing besides simply waiting.
Further, the hot standby system of the present invention may operate alone, and may be connected to a plurality of hot standby systems or ordinary processing servers via a network to perform distributed automatic operation. FIG.
Status management unit 14 and business product restart unit 1
5. Recording a program for realizing the function of the automatic re-executing unit 16 on a computer-readable recording medium,
The program recorded on the recording medium may be read into a computer system and executed, so that the automatic re-execution may be performed in the spare server. In addition,
The “computer system” here includes an OS and hardware such as peripheral devices.

[0032]

As described above, according to the present invention,
The following effects can be obtained. The status management unit is provided on the active server, status information is recorded on the shared disk, and the business product restart unit is provided on the spare server, so that the automatic operation status of business products up to the point of failure in the active server can be monitored. It can be automatically reproduced on the spare server. Further, by providing the automatic re-executing unit, the automatic operation status up to the time when the failure occurs in the active server can be automatically reproduced in the spare server, and the automatic operation by the spare server can be continuously performed. In addition, by providing a status management unit, a business product restart unit, and an automatic re-execution unit in the active server and the spare server, the two servers both have the functions of the active server and the spare server, and failure occurs. Thus, the function as the active server can be exhibited alternately.

[Brief description of the drawings]

FIG. 1 is a diagram showing a configuration of a hot standby system of the present invention.

FIG. 2 is a flowchart showing an operation of the hot standby system of FIG. 1;

FIG. 3 is a flowchart illustrating an operation of a status management unit.

FIG. 4 is a flowchart illustrating an operation of a business-related product restart unit.

FIG. 5 is a flowchart illustrating a re-execution process performed by an automatic re-execution unit.

FIG. 6 is a diagram showing an example of an operation schedule.

FIG. 7 is a diagram illustrating an example of status information.

FIG. 8 is a diagram illustrating an example of an execution history.

FIG. 9 is a diagram showing another example of the execution history.

FIG. 10 is a diagram illustrating an example of a configuration in distributed automatic operation.

FIG. 11 is a diagram showing a configuration of a conventional example of a hot standby system.

FIG. 12 is a flowchart showing the operation of the hot standby system of FIG. 11;

[Description of Signs] 1 Active server 2 Processing unit 3 Shared disk 4 Spare server 5 Processing unit 11 Monitoring unit 12 Failure handling unit 13 Schedule processing unit 14 Status management unit 15 Business product restart unit 16 Automatic rerun unit 17 Various applications 31 Operation schedule 32 Execution history 33 Status information

Claims (8)

[Claims] 1. A shared disk for recording an operation schedule of various jobs, an active server on which jobs are automatically operated based on the operation schedule, and an active server recorded on the shared disk when a failure occurs in the active server. A hot standby system including a spare server that operates as an active server based on the information, wherein the active server is configured to start and stop an application in another job, and to set a status relating to a start status of a business product as status information. The spare server includes a status management unit that records on a shared disk, and the spare server includes a business-related product restart unit that restarts a business-related product by a job with reference to the status information when a failure occurs in the active server. A hot standby system characterized by: 2. The execution history of a job executed by the active server according to the operation schedule is recorded on the shared disk, and the spare server refers to the execution history when a failure occurs in the active server. An automatic re-execution unit for determining a re-execution point in the operation schedule and re-executing a job based on the operation schedule from a job related to the execution point or a succeeding job of the job. The hot standby system according to claim 1, wherein 3. The automatic re-execution unit, when the job at the re-execution point is a job related to the same batch job of terminating the application and terminating the job, if the job is being processed by the active server, The job is re-executed according to the nature of the job, and if the job is being processed by a processing server other than the active server, the job or the job is re-executed according to the processing status or nature of the job at the processing server. 3. The hot standby system according to claim 2, wherein the job is re-executed from a succeeding job. 4. The system according to claim 2, wherein the active server and the spare server include the status management unit, the business product restart unit, and the automatic restart unit, respectively.
Or the hot standby system according to claim 3. 5. A shared disk for recording operation schedules of various jobs, an active server for automatically operating jobs based on the operation schedule, and information recorded on the shared disk when a failure occurs in the active server. An automatic re-execution method in a hot standby system including a spare server operating as an active server based on the active server. Recording information on the shared disk, wherein the spare server refers to the status information when a failure occurs in the active server, and restarts a business-related product by a job. Rerun method. 6. The active server records an execution history of a job executed in accordance with the operation schedule on the shared disk, and the spare server refers to the execution history when a failure occurs in the active server. Determining a re-execution point in the operation schedule, and re-executing a job based on the operation schedule from a job related to the execution point or a succeeding job of the job. 6. The automatic re-execution method in the hot standby system according to 4. 7. A shared disk for recording an operation schedule of various jobs, an active server for automatically operating jobs based on the operation schedule, and information recorded on the shared disk when a failure occurs in the active server. A computer-readable recording medium that records an automatic re-execution program for a hot standby system consisting of a spare server that operates as an active server on the basis of an application server. A status management function for the active server that records status information of the start-up status on the shared disk; and, when a failure occurs in the active server, restarting a business-related product by a job by referring to the status information. Business product restart function for the spare server A recording medium recording an automatic re-execution program for implementing the computer. 8. The automatic re-execution program, when a failure occurs in the active server, refers to an execution history of a job executed according to the operation schedule recorded on the shared disk, and executes the re-execution in the operation schedule. An automatic re-execution function for the spare server, which determines a point and causes the job related to the execution point or a succeeding job of the job to re-execute a job based on the operation schedule is further included. Item 8. A recording medium on which the automatic re-execution program according to Item 7 is recorded.