JP2008003691A - Process recovery method for computer and check point restart system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a check point/restart control technology capable of appropriate recovery when a failure occurs regardless of a factor of the failure. <P>SOLUTION: The process recovery method for a computer holds CP information acquired by a plurality of CP, uses appropriate CP information in accordance with timings of recurrent failures, and recovers the system. The process operating on the computer is monitored, the occurrence of the failure of the process is detected, and a memory state of the process recorded just before an event which influences predetermined security of the process occurs in the process is used to restart the defective process. When the failure recurs within a prescribed period, the memory state recorded further previously is used to restart the process. <P>COPYRIGHT: (C)2008,JPO&INPIT

Description

  The present invention relates to a checkpoint / restart technique for recovering a computer system from a software failure. In particular, the present invention relates to a technique that can be dealt with even when the cause of failure is an attack or intrusion.

  When a computer software or hardware failure occurs, the computer program being executed (hereinafter referred to as a process) interrupts data processing, shifts to the previous process execution state, and continues computer processing. Generally, it is called a checkpoint / restart control method. Process restart (restart) is different from device reboot (restart) that involves system or process stoppage. Restart (restart) is to restore a state by calling a pre-recorded memory or input / output state without stopping the process. The timing for recording this state is called a checkpoint (CP).

  In this specification, information to be duplicated at a checkpoint (CP) is referred to as checkpoint information (CP information), and duplicating the CP information and recording it on a recording medium is referred to as obtaining CP information. Calling CP information and performing state recovery is called recovery processing.

  By the way, depending on the cause of the occurrence of the failure, there is a considerable possibility that the restarted process will fail again.

  In the checkpoint / restart control, restart is attempted using the CP information until the software failure is recovered. However, the number of trials does not exceed a preset maximum value. Alternatively, the trial is repeated within a preset time (see, for example, Patent Document 1).

  In the normal checkpoint / restart control recovery procedure, even when CP information is acquired by a plurality of CPs, restart is attempted using the CP information (latest CP information) acquired immediately before (for example, Patent Document 2).

  As another failure recovery processing method, there is also a method of continuing processing from the next data without processing input data in which a failure has occurred (see, for example, Patent Document 3).

Patent No.3072048 Japanese Patent No. 3135714 JP-A-5-233341

  In general, it is necessary to perform maintenance work as a countermeasure against a failure of a server device. The maintenance work is work related to system integrity, such as application of a security patch and update of a configuration definition file. The specific work content is the exchange of programs and files on the disk. In particular, in a non-stop operation server device, there is a case in which an operation for temporarily suspending data processing of a server and changing a process or data content in a memory and then restarting a job is included.

  The purpose of the maintenance work is to provide a solution in advance and avoid the occurrence of a failure in the server device, assuming threats such as a process losing data or data being tampered with. However, in a situation where the system is large and multiple programs are closely and intertwined, the results and effects of operations that change the computer configuration and program contents cannot be fully understood. is there. For this reason, the state of the process being executed becomes unstable and a failure may occur.

  The types of failure include, for example, the process does not accept a new job, the process abnormally stops, or the process executes an unspecified process. As the cause of these failures, threats such as (X) chance (for example, depletion of resources due to concentration of processing), (Y) accident (for example, malfunction of maintenance work itself), and (Z) attack (for example, virus contamination) are assumed. Is done.

  In general, there are a plurality of computer system operation policies and recovery procedures depending on system targets and failure factors. For example, the recovery procedures differ for the goals of process resumption and failure analysis. As an example of the operation policy, when the cause of the failure can be estimated as either the threat X or the threat Y, the resumption of processing should be given priority. On the other hand, if the failure factor is the threat Z, priority should be given to eliminating the failure factor. In addition, the business may be stopped if it cannot be excluded.

  In either case, the final goal is to resume the work and restore the system, but if the factors can be identified, an appropriate recovery procedure can be selected. Even when checkpoint / restart control is performed, if the cause of the failure is either threat X or threat Y, recovery processing using CP information that prioritizes business resumption is performed and threat Z In some cases, recovery processing should be performed using CP information that can eliminate the cause of failure.

  However, in spite of having inferred the cause of the failure as the threat X, if it is actually the threat Z, the system restarts and the reliability of the work is impaired by advancing the restart time. On the other hand, in spite of the assumption of threat Z, if it is actually threat X, if the stop period is extended indefinitely, economic loss increases.

  Generally, in a non-stop server, when a failure occurs, it is desired to recover as short as possible (in seconds). On the other hand, it is ideal to select a recovery procedure after analyzing the cause of failure. However, failure factor analysis work is often manual work by an expert, and requires a long time (in hours and days). Therefore, it cannot respond to requests from non-stop servers. For this reason, in practice, after recording the type and time of failure, recovery is performed using CP information. Based on the execution result of the recovery processing, the cause of the failure is estimated (the failure has recurred, threat X, not failure Y), and the content and procedure of the recovery processing are adjusted as appropriate.

  By the way, as a phenomenon peculiar to the threat Z, there is a time lag (time difference), that is, the point in time when the failure at which the failure factor is involved in the system becomes apparent is not continuous in time but separated by a period. It is done. Taking a failure due to a virus as an example, there is a time lag between the time when the virus is mixed into the system and the time when the mixed virus is activated and the operation is stopped. For this reason, there is a considerable possibility that CP information is acquired after virus contamination. In this case, when the checkpoint control of the prior art is applied, recovery processing is performed using CP information after virus contamination acquired immediately before the occurrence of a failure. It will be. The cause of the failure (virus) has not been eliminated, and there is a high possibility that the failure will occur again and the business will stop.

  The present invention has been made in view of such circumstances, and even when the cause of a failure is unclear, the system can be safely recovered and the operation can be quickly resumed. The purpose is to provide restart control technology.

  The CP information acquired by a plurality of CPs is held, and the system is recovered using appropriate CP information according to the timing when the failure recurs.

  Specifically, a failure detection step for monitoring a process running on a computer and detecting the occurrence of a failure in the process, and when the occurrence of a failure is detected in the failure detection step, the process predetermined in the process A restarting step for restarting the failed process using the memory state of the process recorded at a timing immediately before the occurrence of an event that affects the integrity of the computer. Provide a process recovery method.

  According to the present invention, it is possible to provide a check checkpoint / restart control technology suitable for a purpose, which is capable of safely recovering a system and quickly restarting a business even when the cause of a failure is unclear. it can.

  Embodiments to which the present invention is applied are shown below. There are two types of checkpoint / restart implementation means: updating the memory of the failed process at restart, or activating the standby process separately from the failed process, depending on the system configuration. . In the following embodiment, as will be described later, since the occurrence of a failure due to an attack is also included, the latter standby process is activated unless otherwise specified.

<< First Embodiment >>
FIG. 1 shows a configuration diagram of an information processing apparatus 500 of this embodiment. As shown in the figure, the information processing apparatus 500 of this embodiment includes a multiprocessor 501, a memory 509, a storage 506, a network interface 507, and an input / output interface 508. The memory 509 includes a volatile memory (DRAM) 504, a phase change memory (PRAM) 505, and a storage (HDD) 506. Here, it is assumed that the multiprocessor 501 includes two processors 502 and 503. However, the number of processors is not limited as long as it is one or more CPUs.

  The HDD 506 is a secondary storage that stores software such as an operating system and application programs as files.

  The DRAM 504 is primary storage for storing software and data such as an operating system and application programs.

  The multiprocessor 501 implements each function described later by loading software stored in the HDD 506 into the DRAM 504 and executing it. The multiprocessor 501 temporarily stores data generated during the processing in the DRAM 504.

  The PRAM 505 holds data used for checkpoint / restart. The data used in the checkpoint / restart is the memory state of the process held as information necessary for restarting at each checkpoint. Hereinafter, the memory state data of the process held at each checkpoint is referred to as checkpoint information (CP information). When the checkpoint acquisition time is represented as CPt, the CP information acquired at the time CPt is referred to as CPt information. The PRAM 505 may not be the phase change memory PRAM 505 as long as it is a nonvolatile memory that is difficult to tamper with.

  The input / output interface 508 transmits an input of a request from an administrator or a supervisor to the multiprocessor 501, and conversely outputs an result processed by the multiprocessor 501, such as a keyboard, mouse, display, etc. Connect with other devices.

  A network interface 507 is a network card connected to an external computer or system.

  FIG. 2 shows a functional configuration realized by the multiprocessor 501 of the present embodiment executing a program. As shown in the figure, the computer system 500 of this embodiment includes an operating system (OS) 1010, an application program (AP) 1000 that runs on the OS 1010, and a library 1020.

  In this embodiment, when the multiprocessor 501 executes a program, in addition to the system call handler 1011 and the system call service routine 1012, a system call monitoring processing unit 1014, a checkpoint / restart processing unit 1013, a library A checkpoint / restart processing unit (L checkpoint / restart processing unit) 1023 and a library function monitoring processing unit 1024 are realized. Also, the storage HDD 506 has an issue history 1015 for recording issued system calls or functions in the order of issue, and a call list 1016 for recording specific system calls, functions, and system call sequences for obtaining checkpoint information. And a library issuance history (L issuance history) 1025 for recording issued library functions in the order of issuance, and a library function list (L call list) 1026 for recording a specific library function for acquiring checkpoint information is recorded. The

  In the example shown in FIG. 2, the system call monitoring unit 1014 and the library function monitoring unit 1024 exist in the library 1020 and the OS 1010, respectively, and operate in cooperation with the dedicated checkpoint / restart function. As described above, in the example shown in FIG. 2, the monitoring unit and the checkpoint / restart function are separated into the library 1020 and the OS 1010, and there are two sets in the system, but only one of these sets exists. It may be configured.

  System calls and functions issued by the monitoring target process 1001 executed by the multiprocessor 501 are recorded in the issue history 1015 in the order of issue as described above. Library calls are also recorded in the L issue history 1025 in the same manner. Therefore, in the following, the case of a system call will be described as an example.

  The call list 1016 stores a predetermined system call sequence, system call, and function.

  The system call monitoring processor 1014 monitors system calls and functions issued by the process 1001 and detects that a predetermined system call sequence, system call and function (hereinafter collectively referred to as a system call sequence) is issued. Notify the checkpoint / restart processing unit 1013. Specifically, the system call sequence issued by the process 1001 and recorded in the issuance history 1015 is checked against the system call sequence recorded in the call list 1016. If they match, the checkpoint / restart processing unit 1013 Notice.

  When the checkpoint / restart processing unit 1013 receives notification from the system call monitoring processing unit 1014 that the data matches, the checkpoint / restart processing unit 1013 records the time and the memory state at that time in the PRAM 505 as time CP and CP information, respectively.

  The checkpoint / restart processing unit 1013 performs recovery processing using the CP information recorded in the PRAM 505 when a failure occurs.

  Details of the processing of the system call monitoring processing unit 1014 and the checkpoint / restart processing unit 1013 will be described below.

  First, the system call sequence monitored by the system call monitoring processing unit 1014 will be described separately for the case where the information processing apparatus 500 is online and the offline state. Here, a case where the information processing apparatus 500 is a UDP server will be described as an example. In the online state, the information processing apparatus 500, which is a UDP server, performs processing by transmitting / receiving information to / from a plurality of UDP clients.

  FIG. 3 is a flow for explaining a typical system call sequence issued for data communication when the server process 1001 of the information processing apparatus 500 (UDP server) executes the initialization process. In the following, it is assumed that the information processing apparatus 500 is hardware, and the process 1001 is software in which server software is running.

(A) UDP server process (information processing apparatus 500) side The UDP server process uses the socket system call to create an endpoint (socket) in order to distinguish the communication path with each client (s701). .

  Next, the UDP server uses the bind system call to name the created socket (s702).

  Then, the UDP server monitors a plurality of sockets using a select system call and waits for data transmission from the client (s703).

  When there is a transmission from the client, the UDP server receives the request data through the socket using the recvfrom system call (s704).

  Then, the UDP server transmits the response data through the socket using the sendto system call (s705). Thereafter, the process returns to a state of waiting for an input from the client (s703).

(B) UDP client side The UDP client uses the socket system call to create an endpoint (socket) for the purpose of communication with a specific UDP server (s711).
The UDP client sends the request data to the UDP server via the socket using the sendto system call (s712).
The UDP client receives the response data from the UDP server via the socket using the recvfrom system call (s713).

  The UDP client repeats s712 and s713 until the process performed with the UDP server is completed, and when the process is completed, performs a close system call and ends the process (s714).

  In this embodiment, the memory state immediately before the state of the process 1001 changes greatly is recorded as CP information. In the present embodiment, when the information processing apparatus 500 is a UDP server, the CP information acquisition timing is determined by paying attention to a typical system call sequence in the above-described UDP server. In the following, a system call sequence that can be determined immediately before the system state is largely changed is referred to as a system call sequence that affects system maintainability.

  First, as a system call sequence that affects system integrity, there is a system call sequence that can detect a state immediately before changing from an offline state to an online state. When the process 1001 starts, the UDP server issues system calls in the order of..., Socket, socket, bind, bind, select, recvfrom,. When the recvfrom system call is issued as described above, the request data is received from the UDP client via the socket, that is, the online use is started. It can be said that the timing at which system calls are issued in the order of socket, socket, bind, bind and subsequently the select system is issued is the memory state immediately before the online state is entered. By acquiring the CP information at this timing, the memory state immediately before online use can be saved as CP information. Note that CP information acquired as a memory state immediately before online is referred to as CP0 information. The time is CP0.

  In the present embodiment, the system call sequence S0 (white list) socket, socket, bind, bind, select is recorded in advance in the call list 1016 as the timing for acquiring the CP0 information. The system call monitoring processing unit 1014 issues a system call in the order of socket, socket, bind, bind, and then issues a select to notify the checkpoint / restart processing unit 1013 to obtain CP information. . Upon receiving the notification, the checkpoint / restart processing unit 1013 records the memory state at that time as CP0 information in the PRAM 505 and records the time CP0 in association with the CP0 information.

  On the other hand, if the issued system call sequence is other, for example,..., Socket, socket, bind, bind, recvfrom,... Are different from the system call sequence recorded in the HDD 506 as the system call sequence S0 in advance. , Do not get memory status.

  Next, a system call sequence that affects system maintainability in an online state will be described. Operations that affect the integrity of the system in the online state include file update and security patch processing.

  FIG. 4 is a diagram for explaining a case where a maintenance operation called file update is performed while the information processing apparatus 500 is online.

In normal times, as shown in FIG. 4, the information processing apparatus 500 (UDP server) repeats recvfrom (S801) and sendto (s802) to advance the process. That is, the issued system call sequence is filled, recvfrom, sendto, recvform, sendto, recvfrom,...
It is.

When a file is updated for maintenance, the operation of the program is changed according to the data input from a remote location, and the binary file and the definition file are updated. At this time, a write system call is issued to write to the file. In this case, system calls are issued in the order of recvfrom (S803), write (s804), and sendto (s805), and the process proceeds. That is, the issued system call sequence is ..., recvfrom, sendto, recvform, write, sendto, recvfrom, ...
It becomes.

  Since the file is rewritten by the write system call, the write system call corresponds to a system call that changes the integrity. Therefore, in order to save the memory state immediately before processing that affects the integrity of the system is performed, CP is issued after the write system call is issued and before the processing is executed in the system call subroutine 1012. Get information.

  That is, when detecting that a write system call has been issued, the system call monitoring processing unit 1014 notifies the checkpoint / restart processing unit 1013 to that effect. Upon receiving the notification, the checkpoint / restart processing unit 1013 records the CP information at that time and the CP indicating the time in the PRAM 505 in association with each other.

  In the above, the case where it is realized by the system call monitoring unit 1014 of the OS 1010 has been described as an example. The process 1001 may be any software called from the AP 1000. The same applies to the case where the library function is monitored and realized by the library monitoring processing unit 1024 of the library 1020 (software that collects functions commonly used by a plurality of applications) existing between the AP 1000 and the OS 1010. Hereinafter, a case where the function is realized by the library function monitoring unit 1024 is described.

  FIG. 5 is a diagram for describing a case where security patch processing is performed while the information processing apparatus 500 is online.

  There are many security patch processes. For example, as a predetermined maintenance procedure in the process 1001, there is one in which the contents of the process 1001 in which a library including a software module for improving maintainability exists or a function is added or a function is added and then the library is unloaded.

  Here, it is assumed that the library is sent from the network 507 and temporarily stored as a file in the storage HDD 506.

  The procedure for performing security patch processing is as follows.

  Upon receiving an instruction to perform security patch processing, the information processing apparatus 500 dynamically loads a library containing maintenance software using the droppen function (s901).

  The process 1001 acquires a maintenance function from the library loaded in s901 using the dlsym function (s902).

  Call maintenance functions and patch memory processes. Here, the mmap system call is used for writing the patch program (s903).

  Unload the library using the dlclose function.

Therefore, here, functions and system calls are issued in the following order.
..., dropen, dlsym, ..., mmap, ..., dlcose, ...
By dynamically loading the library, the memory state changes. Therefore, the process 1001 issues a droppen function and saves the memory state before executing processing inside the library as CP information.

  That is, when the library function monitoring processing unit 1024 detects that the droppen function has been issued, the library function monitoring processing unit 1024 notifies the L checkpoint / restart processing unit 1023 to that effect. When the L checkpoint / restart processing unit 1023 receives the notification, the L checkpoint / restart processing unit 1023 associates the CP information at that time with the CP indicating the time, and records them in the PRAM 505.

  The specific procedure for acquiring CP information in the OS or library when a system call or function for changing maintainability is issued has been described above. As described above, in this embodiment, CP information is automatically acquired by paying attention to maintaining process integrity.

  Here, the reason why the offline state and the online state of the system call sequence to be monitored are separated will be described.

  In the offline state described with reference to FIG. 3, the processing procedure up to the steady state, such as initialization processing, for example, reading of a definition file, is strictly determined. Therefore, there is a high possibility that the system call sequence issued by the process 1001 for each application is uniquely determined. For this reason, it is possible to record a specific system call sequence S0 in advance and collate it with the actually issued system call sequence to determine the CP0 information acquisition timing.

  However, in the online state described with reference to FIGS. 4 and 5, the server program executes different processes in response to requests from the client program. Accordingly, the system call sequence is not uniquely determined and tends to change. Accordingly, there are many types of system call sequences in an application program that implements a complex task, and it is difficult to detect a specific system call sequence limited to maintenance work, for example. In order to detect a specific system call location, for example, it is necessary to manage the operation of the application program and the state of the process, and to confirm the contents of the system call arguments according to the business. .

  However, not all patterns can be extracted in advance for the arguments of the system call sequence, and the confirmation process becomes complicated. For example, the issuance of several tens to several hundreds of connected system calls is recorded as a history, while the corresponding system call sequence is distinguished from normal status, abnormal status, status requiring monitoring, exception handling, maintenance work, etc. It is necessary to prepare a list with tens, for example, tens to thousands. In addition, executing the above-described confirmation process every time a system call is issued delays the original data processing of the business.

  Even when online, it is desirable to monitor the system call queue. However, as described above, depending on the characteristics of the application program, it takes time to check the validity of the system call. For this reason, there is a possibility that a delay occurs in the original data processing. Therefore, it is desirable to keep monitoring system calls alone.

  Therefore, in order to confirm in real time while maintaining detection accuracy to some extent in the online state, CP information is acquired when a specific system call or function is issued instead of a system call sequence.

  That is, the system call string (system call issue order) is strictly monitored offline, and whether a specific system call or function is issued online is monitored.

  Next, when the checkpoint / restart processing unit 1013 of the present embodiment restarts, the failure factor is classified, and the re-failure life T and the recurrent failure interval T ′ to be introduced to determine the subsequent processing are determined. explain.

  When a failure occurs, the checkpoint / restart processing unit 1013 records the time when the failure occurs and restarts using predetermined CPi information to perform a recovery process.

  The time when the first failure occurs is assumed to be t1. The time from the time CPi when the CPi information used for the recovery process is acquired to the time t1 when the failure occurs is referred to as a re-failure life T of the CPi information as a predicted time when the failure occurs again. Also, the time from the time CPi at which the CPi information used for the recovery process is acquired to the time t2 at which the failure occurs again after the recovery process is referred to as the CPi information recurrent failure interval T ′ as the time at which the failure actually recurs. . The re-failure life T and the recurrent failure interval T ′ are calculated by the checkpoint / restart processing unit 1013 each time a failure occurs.

  When the first failure occurs, the checkpoint / restart processing unit 1013 performs recovery processing using the latest CP information. If the same failure occurs for the second time before obtaining the next CP information, the checkpoint / restart processing unit 1013 compares the re-failure life T of the CP information used for the recovery processing with the recurrent failure interval T ′. If the re-failure life T is shorter than the recurrent failure interval T ′, the recovery process is continued using the same CP information even when the same third failure occurs.

  On the other hand, when the same failure occurs for the second time and the recurrent failure interval T ′ is equal to or shorter than the re-failure life T, the checkpoint / restart processing unit 1013 performs the latest CP information once used for the recovery processing once. The recovery process is performed using the previously saved CP information.

  When the same third failure occurs before the next CP information is acquired, the checkpoint / restart processing unit 1013 similarly uses the CP information re-failure life T and recurrent failure time interval T ′ used for the recovery processing. When T <T ′, the same CP information is used for recovery processing. On the other hand, when T ≧ T ′, the recovery process is further performed using the CP information recorded once more.

  Note that calling the CP information to recover the state is defined as restarting. In the present embodiment, since a plurality of pieces of CP information are held, when a failure occurs again, there are cases where the same CP information as in the previous restart is used and cases where another CP information is used. Here, performing recovery processing using the same CP information is referred to as retry, and performing recovery processing using new CP information is referred to as restarting.

  As described above, in this embodiment, the checkpoint / restart processing unit 1013 compares the re-failure life T with the recurrent failure interval T ′ when the same failure recurs before acquiring new CP information. When T <T ′, retry is performed. When T ≧ T ′, restart is performed using the CP information recorded one time before the CP information previously restarted.

  In the above, since the CP information recorded at the nearest time point is closest to the state at the time of the failure, the previous CP information is used at the time of the failure, and the previous CP information is used at the time of the failure again. Although the case has been described as an example, the CP information to be used is not limited to this. You may comprise so that CP information traced back by predetermined amount may be used.

  In this embodiment, every time a failure occurs, the checkpoint / restart processing unit 1013 records an error code issued by the OS 1010 or the process 1001 of the information processing apparatus 500 in a memory such as the PRAM 505 along with the time. Using this record, the checkpoint / restart processing unit 1013 determines whether the same failure or a different failure has occurred for the second and subsequent failures.

  Next, the process in which the checkpoint / restart processing unit 1013 performs a retry or restart will be described using a specific example with reference to FIG.

  FIG. 6 is a diagram for explaining how the checkpoint / restart processing unit 1013 performs a retry or restart according to the relationship between the re-failure life T of the CP information and the recurrent failure interval T ′ of the CP information. .

  In this figure, the CP information acquired immediately before the online state in the offline state is referred to as CP0 information, the time is referred to as CP0, and the timing at which the CP information is acquired in the online state is defined as CP1, CP2,. , CPn, CPn + 1, and the CP information recorded in the PRAM 505 in association with each time is called CP1 information, CP2 information,..., CPn-1 information, CPn information, CPn + 1 information, respectively. Hereinafter, the same failure is represented by the same letter, and the number of failures is indicated by a dash. In the figure, P ′ and P ″ indicate restart and retry start points.

  FIG. 6A shows an example in which the relationship between the re-failure life Tn of the CPn information and the recurrent failure interval Tn ′ of the CPn information is Tn <Tn ′ and the retry is performed using the CPn information. A failure due to an accident is likely to have such an occurrence pattern. This corresponds to the procedure in the conventional method.

  After the CPn information is recorded at the time CPn, when the first failure X occurs at the time tx before the next CPn + 1 information is recorded, restart is performed using the CPn information recorded immediately before. Specifically, when a failure X occurs, the checkpoint / restart processing unit 1013 determines the CPn information recorded immediately before as CPn information to be used for restarting, and restarts using the CPn information.

  The re-failure life Tn of CPn is the time from the time CPn at which the previous CPn information is acquired to the time tx when the failure X occurs. On the other hand, when the failure X ′ (second failure X ′) occurs again after the recovery process and before the time CPn + 1 for obtaining the next CP information CPn + 1 information, the re-failure interval Tn ′ of CPn is: This is the time tx ′ until the failure X ′ actually occurs again after restarting using the CPn information.

  Here, since the re-failure interval Tn ′ of CPn is longer than the re-failure life Tn of CPn and Tn <Tn ′, the checkpoint / restart processing unit 1013 performs retry using the CPn information.

  At this time, if the CPn + 1 information is acquired before the failure X ″ occurs, the recovery process is performed using the CPn + 1 information when the failure X ″ occurs.

  FIG. 6B shows that the relationship between the re-failure life Tn of the CPn information and the recurrent failure interval Tn ′ of the CPn information is Tn ≧ Tn ′, and the CPn-1 information recorded one time before the CPn information is used. When restarting, the relationship between the re-failure life Tn-1 of the CPn-1 information and the recurrent failure interval Tn-1 'of the CPn-1 information becomes Tn-1 <Tn-1', and thereafter, CPn-1 It is an example in the case of repeating the retry using. A failure due to an accident is likely to have such an occurrence pattern.

  If the first failure Y occurs after the CPn information is acquired at the time CPn and before the next CPn + 1 information is acquired, the checkpoint / restart processing unit 1013 immediately before the procedure described with reference to FIG. Restart using the recorded CPn information. The re-failure life Tn of CPn is the time from CPn when the previous CP information was acquired to the time of failure Y occurrence ty, and the re-failure interval Tn ′ is the second failure Y ′ after restart using the CPn information. This is a time ty ′ until occurrence of. Here, Tn ≧ Tn ′.

  The re-failure life Tn-1 of CPn-1 is the time from the time CPn-1 when the CPn-1 information is acquired to the time tx when the failure Y occurs. On the other hand, when the failure Y ″ (third failure Y ″) occurs again after the recovery process and before the time CPn + 1 for obtaining the next CP information, CPn + 1 information, the re-failure interval of CPn−1 Tn-1 ′ is a time ty ″ until the failure Y ″ actually occurs again after restart using the CPn-1 information. Here, since Tn-1 <Tn-1 ', the checkpoint / restart processing unit 1013 performs a retry using the CPn-1 information.

  FIG. 6C shows an example in which the relationship between the re-failure life T of the CP information and the recurrent failure interval T ′ of the CP information is repeatedly T ≧ T ′. Every time the same failure occurs, restart is performed using the CP information recorded once more. Finally, restart is performed using the CP0 information in which the memory state immediately before connection to the network is recorded. For example, in the case of a failure caused by an attack by a virus, there is often a time lag between the time when the virus is taken in and the time when the failure occurs. In such a case, there is a high possibility that a failure occurrence pattern as shown in FIG.

  If the first failure Z occurs after the CPn information is acquired at the time CPn and before the next CPn + 1 information is acquired, the checkpoint / restart processing unit 1013 immediately follows the procedure described in FIG. Restart using the recorded CPn information. The re-failure life Tn of CPn is the time from CPn when the previous CP information was acquired to the time tz when the failure Z occurred, and the re-failure interval Tn ′ is the second failure Z ′ after restart using the CPn information. Is the time tz ′ until occurrence of. Here, Tn ≧ Tn ′.

  The re-failure life Tn-1 of CPn-1 is the time from the time CPn-1 when the CPn-1 information is acquired to the time tz when the failure Z occurs. On the other hand, if the failure Z ″ (third failure Z ″) occurs again after the recovery process and before the time CPn + 1 for obtaining the next CP information, CPn + 1 information, the recurrent failure interval of CPn−1 Tn-1 ′ is a time tz ″ until the failure Z ″ actually occurs again after restarting using the CPn-1 information. Again, since Tn−1 ≧ Tn−1 ′, the checkpoint / restart processing unit 1013 returns to the CPn−2 information recorded one more time before.

  The checkpoint / restart processing unit 1013 calculates and compares the re-failure life T and the recurrence failure interval T ′ every time a failure occurs, and re-uses the CP information from the previous one as long as T ≧ T ′. The starting is repeated until the CP information to be used becomes the CP0 information.

  In the case of FIG. 6C, each time the failure recurs, it is retroactively restarted using the CP information one by one, but this is not a limitation. For example, if the failure recurs after restarting using CPn information at the time of the first failure, it is configured to restart using CP0 information. For example, the number of times CP information is used sequentially before using CP0 information. It may be determined in advance.

  Next, the time recorded by the checkpoint / restart processing unit 1013 every time a failure occurs will be described. When the information processing apparatus 500 is executed with a single service and a single process, there is no problem, but when multiple services and multiple processes are executed in parallel, the processing time is being measured. It may be affected by processes other than the process 1001.

  Generally used as system time include elapsed time 401, user time 402, and system time 406. FIG. 7 is a diagram for describing these three types of time 401, user time 402, and system time 406 using a model. When each CPn information is acquired, these times are recorded in the PRAM 505 as CPn.

  The elapsed time 401 corresponds to the time when the information processing apparatus 500 is viewed from the outside. The user time 402 is a time when the process 1001 is operated in the user mode (a state where the protected subsystem and the application program 1000 that are classified as a part of the OS 1010 operate), and the system time 406 is a process time. Reference numeral 1001 denotes a time during which the system operates in a kernel mode (a state in which only a primitive OS function such as a scheduler, memory management, and process management operates).

  Also, in this figure, the cumulative counts 405 and 407 are cumulative values of the number of system call issuances. Since the time measurement by the multiprocessor 501 may not always be accurate, using the accumulated value of the number of system call issuances (accumulated number of system calls 405 and 407) makes it easier and more accurate. There are cases where it can be done. These are used in a second embodiment to be described later. In the second embodiment, the recovery processing procedure at the time of failure is determined using the cumulative number 405 and 407 of system calls.

  Which time is used for calculating the re-failure life T and the recurrent failure interval T ′ is preferably used depending on the type of attack. For example, in the case of an attack that executes an infinite loop and wastes CPU execution time, the user time 402 is used. By repeating the issuance of system calls that perform time-out I / O, it is possible to measure the time with high accuracy according to the attack by selecting each system time if it is an attack that wastes CPU execution time. It becomes.

  Next, a processing flow in which the checkpoint / restart processing unit 1013 according to the present embodiment acquires CP information while monitoring a predetermined process 1001, and performs recovery processing using the acquired CP information when a failure occurs. Will be described.

  FIG. 8 is a processing flow of CP information acquisition processing in which the checkpoint / restart processing unit 1013 acquires CP information based on a notification from the system call monitoring processing unit 1014.

  In the present embodiment, the maximum number of CP information stored in the PRAM 505 in the online state is referred to as the generation number m. When CP information other than the CP0 information is newly acquired beyond the generation number m, the CP information is deleted in order from the oldest one. For example, when the number of generations m is set to 2, the latest information and the CP information for the previous two times are stored. The method for determining the number of CP information to be stored is not limited to this method. For example, the maximum capacity of the storage destination PRAM 505 may be recorded, and thereafter, the oldest one may be overwritten in order to erase.

  The number of times CP information is acquired in the online state is referred to as a cumulative number n. Hereinafter, using the cumulative number n, the time at which CP information is acquired is represented as CPn, and the CP information acquired at CPn is represented as CPn information.

  When the process 1001 starts processing, the checkpoint / restart processing unit 1013 refers to the generation number m for storing the CP set in advance by the administrator or the like (s601).

  The checkpoint / restart processing unit 1013 sets a counter for counting the number of CP information to be stored as n (referred to as a cumulative number), and sets an initial value 0 to the cumulative number n (s602).

  The system call monitoring processing unit 1014 monitors the system call sequence S issued by the process 1001 (S603). When the information processing apparatus 500 is in an offline state, the system monitoring processing unit 1014 monitors whether the system call sequence S0 has been issued. When it is detected that a system call sequence S0 stored in the call list 1016 has occurred during monitoring (s604), the system call monitoring processing unit 1014 notifies the checkpoint / restart processing unit 1013 of the detection. Upon receiving the notification, the checkpoint / restart processing unit 1013 sets CP0 as the time when the notification is received, and obtains CP information by duplicating the memory state of the process 1001 at the time of CP0 on the DRAM 504 to obtain CP0 information ( s605).

  The checkpoint / restart processing unit 1013 sets the time CP0 as the time t0, transfers the CP0 information acquired in S604 from the DRAM 504 to the PRAM 505, and records the CP0 information in the PRAM 505 in association with the time CP0 (s606).

  When it is detected that the information processing apparatus 500 is connected to another apparatus or system via the network interface 507 (s607), the system call monitoring processing unit 1014 monitors the system call sequence S of the process 1001 in the online state. Switch to.

  In the online state, the system call monitoring processing unit 1014 continuously monitors the system call sequence S issued by the process 1001 (s608). Here, the system call monitoring processing unit 1014 monitors whether or not the above-described write system call or function droppen is issued. In the online state, the checkpoint / restart processing unit 1013 monitors the occurrence of a failure. If a failure is detected (s609), CP recovery processing in FIG. 9 described later is performed.

  When the system call monitoring processing unit 1014 detects a predetermined system call or function in the online state during monitoring of the system call sequence S, it notifies the checkpoint / restart processing unit 1013 (s610).

  The checkpoint / restart processing unit 1013 increments the cumulative number n by 1 (s611), and acquires the detection time CPn and the memory state at the time of CPn as CPn information in the same manner as s605 (s612).

  Next, the checkpoint / restart processing unit 1013 compares the cumulative number n with the generation number m (s613). When the cumulative number n is larger than the number of generations, the number of generations m is already recorded in the PRAM 505. In this case, the oldest CP information (here, CPn-m information) is deleted from the PRAM 505, and the newly acquired CPn information is recorded in the PRAM 505 (s614, s615).

  Specifically, when the cumulative number n is larger than the generation number m as a result of the comparison in S613, the CPn-m information that is the oldest CP information in the PRAM 505 is deleted from the PRAM 505. Thereafter, the newly acquired CPn information is recorded in the PRAM 505. On the other hand, as a result of the comparison in s613, when the cumulative number n is less than or equal to the generation number m, the process of S614 is not performed, and the newly acquired CPn information is recorded in the PRAM 505 (s614, s615).

  Thereafter, the system call monitoring processor 1014 returns to the state of monitoring the system call queue (s608).

  Next, CP recovery processing when the checkpoint / restart processing unit 1013 detects a failure in the CP information acquisition processing shown in FIG. 8 will be described. FIG. 9 is a processing flow of CP recovery processing.

  When detecting the failure, the checkpoint / restart processing unit 1013 records the failure occurrence time (time when the failure is detected) tx in the PRAM 505 (s101). Then, the information processing apparatus 500 is set offline (line disconnection process) (s102).

  Further, the checkpoint / restart processing unit 1013 substitutes the cumulative number n at that time for the counter i (s103). Then, it is determined whether or not CPi information is recorded in the PRAM 505 (s104).

  If not recorded in s104, the process proceeds to s113 described later.

  On the other hand, if it is recorded in s104, the checkpoint / restart processing unit 1013 restarts using the time CPi at which the CPi information recorded in association with the CPi information is acquired and the previously recorded failure time tx. The failure life Ti is calculated and substituted (Ti = tx−CPi) (s105).

  Then, the checkpoint / restart processing unit 1013 performs recovery processing using the CPi information (s106).

  When recovery processing is performed and the online state is entered (s107), the checkpoint / restart processing unit 1013 continues to monitor the occurrence of a failure (s108). If the system call monitoring processing unit 1014 detects the system call sequence S before the checkpoint / restart processing unit 1013 detects a failure, the process returns to step s611 in FIG.

  On the other hand, when the checkpoint / restart processing unit 1013 detects the same failure as the previously detected failure before the system call monitoring processing unit 1014 detects the system call sequence S (s108), the time tx ′ at which the failure is detected Record (s109). Then, offline (line disconnection) is performed (s110).

  Then, the checkpoint / restart processing unit 1013 calculates the recurrent failure interval Ti ′ using the time tx ′ and the time CPi (Ti ′ = tx′−CPi) (s111).

  Then, the checkpoint / restart processing unit 1013 compares the re-failure life Ti with the recurrent failure interval Ti ′ (s112).

  If the failure recurs after the period of the re-failure life Ti has passed, that is, if the re-failure life Ti is equal to or greater than the re-failure interval Ti ′ (Ti ≧ TI ′), the process returns to step S106 and is recovered using the same CPi information. Process (retry).

  On the other hand, if a failure occurs before the re-failure life Ti, that is, if the re-failure life Ti is shorter than the recurrent failure interval Ti ′ (Ti <Ti ′), the counter i is decremented by 1 (s113), and the counter i is negative. (S114), if it is a negative value, the checkpoint / restart processing unit 1013 stops the task (process 1001) (s115).

  On the other hand, if the counter i is not a negative value (s114), the process returns to step S105, and recovery processing is performed using the CPi information recorded once before (restart: retreat of CP information).

  The CP recovery process by the checkpoint / restart processing unit 1013 of this embodiment has been described above.

  In the present embodiment, as described above, the time from the time (CP) when the CP information for starting the process is acquired to the time of failure is measured and set as the re-failure life. After the failure occurs, the process is restarted using predetermined CP information. Then, the time from the time when the CP information used at the time of restarting is acquired until it fails again is measured and set as the recurrent failure interval. The re-failure life is compared with the recurrent failure interval, and if the process has a re-failure life longer than the recurrent failure interval, the process is restarted using the CP information acquired once before. At this time, the re-failure life is reset based on the elapsed time from the time when the CP information used for the restart is acquired to the first failure. Note that the user time of the process is used instead of the real time of the process. Alternatively, the system time of the process can be used.

  In this embodiment, CP information used for recovery processing (restart, retry) is automatically acquired when a predetermined system call sequence is detected. In other words, the OS itself acquires the CP information, not the AP embedding or the operator's operation.

  Specifically, the information processing apparatus according to the present embodiment includes a unit that monitors a system call, and a unit that refers to a list of system calls that is called from the unit and changes the integrity of a process to be monitored. . In addition, there are provided means for obtaining CP information of the online process and means for restarting the process using arbitrary CP information. Furthermore, a means for replicating the file called from the means for obtaining the CP information and a means for restoring the file called from the means for restarting the process are provided.

  Specifically, system calls that change maintainability include system calls that switch from online to offline, system calls that update files related to monitored processes, and system calls that apply security patches to monitored processes. . Therefore, according to this embodiment, this configuration makes it possible to acquire necessary and sufficient CP information in an unattended operation (and non-stop operation) system.

  According to the present embodiment, the CP information just before online as well as during online is acquired. Therefore, at least one piece of CP information that can be recovered to a safe state can be secured.

  According to the present embodiment, since the CP information is acquired upon detection of a predetermined system call sequence, necessary and sufficient CP information can be automatically acquired and held. Therefore, it is possible to prevent waste of recording capacity by holding CP information indefinitely, and efficiently hold CP information effective for performing recovery processing.

  Further, according to the present embodiment, since the concept of re-failure life is introduced, it is possible to perform recovery processing by selecting appropriate CP information by comparing the time when the failure recurs with the re-failure life. That is, optimal CP information can be sequentially selected and recovered based on the phenomenon of failure recurrence without clearly determining the cause of the failure (type of threat) immediately after the first failure. .

  In other words, it is possible to provide a checkpoint / restart control technique that can select an appropriate recovery procedure when a failure occurs, using a plurality of necessary and sufficient CP information, regardless of whether or not failure analysis has occurred.

  Further, according to the present embodiment, the system call monitoring function is a function for instructing the checkpoint / restart processing unit 1013 to acquire CP information in the checkpoint / restart processing unit 1013 or to perform restarting. Means are provided in the OS in the same manner as the checkpoint / restart processing unit 1013. For this reason, compared with the case where an instruction such as CP information acquisition is received from the process 1001, which is an application executed outside the OS, it is less likely to be affected by unauthorized code intrusion. In other words, when an instruction is received from the process 1001, if an illegal code is inserted into the process 1001, it is easy to receive an operation such as avoiding acquisition of CP information or performing unlimited execution. However, there is no such anxiety in the configuration of the present embodiment.

  As described above, according to the present embodiment, it is possible to provide a checkpoint / restart technique that can efficiently use a memory and perform an appropriate recovery process according to a failure occurrence state.

<< Second Embodiment >>
Next, a second embodiment to which the present invention is applied will be described. In the first embodiment, the concept of re-failure life T calculated from the failure time and the CP information acquisition time is introduced in order to determine which CP information is used for the recovery process. However, in this embodiment, instead of introducing time, the number of system calls issued is measured.

  The functional configuration and hardware configuration of the information processing apparatus 500 of this embodiment are basically the same as those of the first embodiment. Hereinafter, a configuration different from the first embodiment of the present embodiment will be described.

  In this embodiment, a checkpoint / restart processing unit 1013-2 is provided instead of the checkpoint / restart processing unit 1013. After acquiring the CP0 information, the checkpoint / restart processing unit 1013-2 counts the number of subsequent system calls issued. Each time CP information is acquired, the cumulative number of system calls issued SCi is recorded in the PRAM 505 in association with the CPi information instead of the time CPi at which the CPi information is acquired. Similarly, when a failure occurs, the checkpoint / restart processing unit 1013 records the cumulative number of system calls issued SCx up to that time instead of the occurrence time tx.

  That is, in the CP information acquisition process, the time at which the CP information is acquired is not recorded in the present embodiment. On the other hand, when the system call is monitored, the number of system calls issued is counted. Further, when a failure occurs, the cumulative number of system calls issued SCx at the time of failure is recorded, not the failure time tx.

  In the present embodiment, the re-failure life T is defined as the cumulative number of system calls issued SCx at the time of recent CP information (CPi information) acquisition from the cumulative number of system calls issued SCx at the time of failure. (Ti = SCx-SCi).

  FIG. 10 is a processing flow of CP recovery processing according to this embodiment.

  When the checkpoint / restart processing unit 1013-2 detects a failure, the checkpoint / restart processing unit 1013-2 records the cumulative system call (SC) number SCx at that time in the PRAM 505 (s301). Then, the information processing apparatus 500 is set offline (line disconnection process) (s302).

  The checkpoint / restart processing unit 1013-2 substitutes the cumulative number n at that time for the counter i (s303). Then, it is determined whether or not CPi information is recorded in the PRAM 505 (s304).

If not recorded in s304, the process proceeds to s314 described later.
On the other hand, if it is recorded in s314, the checkpoint / restart processing unit 1013-2 previously records the cumulative system call number SCi at the time when the CPi information recorded in association with the CPi information is acquired. The re-failure life Ti is calculated using SCx at the time when the failure is detected, and is substituted into the counter C (C = Ti = SCx−SCi) (s305).

  Then, the checkpoint / restart processing unit 1013-2 performs recovery processing using the CPi information (s306).

  When the recovery process is performed and the online state is entered (s307), the checkpoint / restart processing unit 1013-2 first sets a CP information acquisition flag. Here, the CP information acquisition flag is a configuration unique to the present embodiment, and the checkpoint / restart processing unit 1013-2 is configured so that the CP is not detected even if the system call sequence S is detected while this flag is set. It is configured not to obtain information.

  Then, the checkpoint / restart processing unit 1013-2 continues to monitor the occurrence of a failure (s308). Here, it is determined whether or not a failure has occurred each time a system call is issued.

  If no failure is detected, the checkpoint / restart processing unit 1013-2 decrements the counter C by 1 (s309). At this time, the cumulative number of system calls issued SC is incremented by 1 as usual. Then, it is determined whether or not the counter C is 0 (s310). If the counter C is not 0, the process returns to s308 and continues to detect whether or not a failure has occurred every time a system call is issued.

  In this embodiment, since the recurrent failure life is defined by the number of system calls issued, it can be said that the recurrent failure life Ti is reached when the counter C becomes zero. When the counter is 0 in s310, the checkpoint / restart processing unit 1013-2 lowers the CP information acquisition flag (s311). Thereafter, if the system call monitoring processing unit 1014 detects the system call sequence S before the checkpoint / restart processing unit 1013-2 detects a failure, the process returns to step s611 in FIG. With this configuration, in this embodiment, the CP information is not acquired during the recurrent failure life Ti.

  Then, the failure monitoring is continued (s311). If the same failure recurs, it means that the failure has recurred at a time exceeding the recurrent failure life Ti. While the occurrence of a failure is not detected, monitoring is continued until the system call sequence S is detected.

  On the other hand, when the checkpoint / restart processing unit 1013-2 detects the same failure as the previously detected failure in s308, the failure has recurred during the recurrent failure life Ti. Go offline (s313), decrement the counter by 1 (i = i-1) (s314), and return to s305 while i is greater than or equal to 0 and continue processing (restart; retreat of CP information to be used). On the other hand, if the result of decrementing i is negative, the checkpoint / restart processing unit 1013-2 stops the task (process 1001) (s316).

  If not recorded in s304, the process proceeds to s314 described later. On the other hand, if it is recorded in s304, the checkpoint / restart processing unit 1013-2 adds to the system call counter C introduced for counting the number of system calls the cumulative number of system calls issued at the time of failure SCx. Then, the re-failure life Ti is calculated and substituted from the cumulative issuance number SCi of system calls at the time when the latest CP information (CPi information) is acquired (S305).

Also, the checkpoint / restart processing unit 1013-2 performs recovery processing using the CPi information (S306). In the present embodiment, a CP information acquisition stop flag is introduced. While the CP information acquisition stop flag is set, CP information is not acquired even if a predetermined system call sequence is detected. Offline Here, the CP information acquisition stop flag is set. As described above, according to the present embodiment, the number of system call issuances is used instead of the time in order to determine the processing after the occurrence of a failure. Therefore, in addition to the effects obtained in the first embodiment, the processing can be realized with a simple subtraction counter, and the system configuration can be simplified.

  In addition, according to the present embodiment, the counter C is used so long as the re-failure life is not exceeded (until the counter C reaches 0), for example, in a system that is unlikely to cause a continuous failure, The system can be configured not to acquire. On the other hand, when the re-failure life period is exceeded, when a predetermined system call is issued, the process returns to the normal process of obtaining CP information. That is, CPk (CPn + 1 in FIG. 10) is acquired in FIG. As described above, it is possible to determine the CP information acquisition in consideration of the re-failure life.

  In the above embodiments, the functional configuration has been described by taking the example shown in FIG. 2 as an example, but is not limited thereto. For example, the configuration shown in FIG.

  The configuration shown in FIG. 11 is obtained by applying a virtualization technology (hypervisor) of a computer apparatus to the information processing apparatus 500.

  In FIG. 11, the information processing apparatus 500 includes a business system and a monitoring system. The business system includes an application program 1000 and its alternative 1100, and an operating system 1010 and its alternative 1110. The monitoring system includes a monitoring process 1200 and an operating system 1210. The application program 1000, its alternative 1100, the monitoring process 1200, and the operating system 1010, its alternative 1110, and the operating system 1210 are combined by a virtual machine 1150. The checkpoint / restart processing unit 1013 is provided in the virtual machine 1150. In this case, since the checkpoint / restart processing unit 1013 is also hidden from the operating system, the safety is further improved.

  In this figure, an application program 1000 and its alternative 1100 include a binary program 1002 and a setting file 1003 related to the target process 1001. By using the virtualization technology, it becomes easy to store each binary program 1002 and the setting file 1003. Therefore, according to this configuration, not only the memory but also the program and the setting file are duplicated. According to this configuration, the maintenance work itself is estimated, and files related to the process are backed up. For this reason, it is possible to protect against a file required for restarting against an attack camouflaged in the maintenance work itself.

  The monitoring process 1200 registers a system call monitoring processing unit 1014 and a call list 1016 that records a system call sequence for obtaining CP information in each operating system 1010. When the operating system 1010 detects a system call sequence recorded in the call list 1016, the operating system 1010 issues a request to the checkpoint / restart processing unit 1013 included in the virtual machine virtual machine 1150, and the application program 1000 and the operating system 1010 All of the computer environment including is copied as CP information. When a failure occurs in the application program 1000 or the operating system 1010, a restart instruction is issued from the alternative application program 1100 and the operating system 1110.

  The monitoring process 1200 indirectly monitors the failure of the monitoring target process 1001 of the application program 1000. With such a configuration, it is possible to maintain independence between systems, and it is difficult for viruses and the like to enter the monitoring system from the business system. Conversely, the monitoring system is less likely to affect the business system. Further, in this figure, the case where the number of monitoring target processes 1001 (application program 1000) is 1 is described as an example. However, the number of monitoring target processes 1001 is not limited to this. In the case where there are a large number of monitoring target processes 1001 such as several tens to several hundreds, and there is only one monitoring process, a monitoring process is performed for a failure of the monitoring target process 1001 of the application program 1000 as shown in FIG. If the 1200 is configured to indirectly monitor, the monitoring system is less likely to become a bottleneck in the processing of the entire system.

  As described above, according to the present embodiment, CP information is acquired when a predetermined system call is issued. Therefore, compared with the case of regularly acquiring CP information, the safety is high and necessary and sufficient CP information can be acquired. For this reason, it is highly possible to recover from a meaningful point in maintenance work.

It is a block diagram of the information processing apparatus of 1st embodiment. It is a functional lineblock diagram of the information processor of a first embodiment. It is a figure for demonstrating the system call sequence which the information processing apparatus of 1st embodiment issues in an offline state. It is a figure for demonstrating the system call sequence which the information processing apparatus of 1st embodiment issues in an online state. It is a figure for demonstrating the system call sequence which the information processing apparatus of 1st embodiment issues in an offline state. It is a figure for demonstrating the retry and restart of 1st embodiment. It is a figure for demonstrating the kind of time of 1st embodiment. It is a processing flow of CP information acquisition processing of the first embodiment. It is a processing flow of CP recovery processing of the first embodiment. It is a processing flow of CP recovery processing of the second embodiment. It is another functional block diagram of information processing apparatus.

Explanation of symbols

500: Information processing apparatus, 501: Multiprocessor, 502: Processor, 503: Processor, 504: Volatile memory DRAM, 505: Phase change memory PRAM, 506: Storage HDD, 507: Network interface, 508: Input / output interface, 1000 : Application program, 1001: Process to be monitored, 1010: Operating system, 1011: System call handler, 1012: System call service routine, 1013: Checkpoint / restart processing unit 1013, 1014: System call monitoring processing unit, 1015: Issue History, 1016: Call list

Claims (10)

A failure detection step for monitoring a process running on the computer and detecting the occurrence of a failure in the process;
When the occurrence of a failure is detected in the failure detection step, the failure is detected using a memory state of the process recorded at a predetermined timing before an event that affects the process integrity determined in advance in the process. And a restart step for restarting the process in which the error occurred. A computer process recovery method comprising: A process recovery method according to claim 1, comprising:
The failure detection step records the type and time of the failure detected each time the occurrence of the failure is detected,
The restart step records the memory state used for restart from the time when the memory state used for restart when the same fault occurrence was detected last time to the newly detected fault occurrence time If it is longer than the time from the time of failure to the time of the previous failure, restart using the memory state used at the time of the previous failure, and if shorter, record before the memory state used at the time of the previous failure. A process recovery method characterized by restarting using the selected memory state. A process recovery method according to claim 1, comprising:
When the occurrence of a failure is detected, the failure detection step records the type of the detected failure and the number of system calls issued until the occurrence of the failure is detected from the operation of the process,
In the restart step, the number of system calls issued from the time when the memory state used for the restart was recorded when the occurrence of the same failure was detected last time to the time of the newly detected failure is recorded. If the number of system calls issued from the time of failure to the time of the previous failure is greater than the number of system calls, restart is performed using the memory state used at the time of the previous failure. A process recovery method comprising performing restart using a memory state recorded before the memory state. A memory status recording method used to perform recovery processing when a failure occurs in a process running on a computer,
A monitoring step for monitoring the system call queue issued by the process;
In the monitoring step, when a system call sequence indicating that a process that has an influence on the integrity of the process is performed is detected, the memory state of the process at the time is correlated with the detected time. A memory status recording step for recording;
A memory status recording method comprising: The memory status recording method according to claim 4,
When the computer is in an offline state, the memory state is recorded triggered by detection of a system call sequence indicating immediately before the transition from the offline state to the online state,
When the computer is in an online state, the memory state is recorded in response to detection of a system call sequence indicating immediately before either file update or program addition processing for correcting a security vulnerability is performed. A memory state recording method. A system call monitoring means for monitoring a system call issued in a process running on a computer and detecting the issuance of a predetermined system call sequence;
When the system call monitoring unit acquires the memory state of the process at the timing when the predetermined system call sequence is detected, records the memory state in association with the acquired time, monitors the process state, and detects a failure. Recording restart means for restarting the process using the recorded memory state,
The checkpoint restart system, wherein the predetermined system call sequence is a system call sequence indicating that an event affecting the integrity of the process is just before the occurrence. The checkpoint restart system according to claim 6, wherein the recording restarting means includes:
Record the type and time of the detected failure every time a failure is detected,
The time from the time when the memory state used for the restart was recorded when the same failure occurrence was detected last time to the time when the newly detected failure occurred was recorded from the time when the memory state used for the restart was recorded. If it is longer than the time up to the time of occurrence, restart using the memory state used at the time of the previous failure, and if shorter, use the memory state recorded before the memory state used at the time of the previous failure. A checkpoint restart system characterized by restarting. The checkpoint restart system according to claim 6, wherein the recording restarting means includes:
When the occurrence of a failure is detected, the type of the detected failure and the number of system calls issued from the start of the process until the occurrence of the failure is recorded.
The number of system calls issued from the time when the memory state used for restart was recorded when the occurrence of the same failure was detected last time until the time of the newly detected failure was recorded from the time when the memory state was recorded. If the number of system calls issued is greater than the number of system calls issued before the occurrence of a fault, restart is performed using the memory state used at the time of the previous failure, and if it is less, it is recorded before the memory state used at the time of the previous failure. A checkpoint restart system characterized by restarting using the selected memory state. A computer system including a virtual machine on which a plurality of application programs (AP) and a plurality of operating systems (OS) operate,
Each OS includes a system call monitoring unit that monitors a system call issued by an AP (process) being executed on the OS and detects an issuance of a predetermined system call sequence.
The virtual machine is
All memory states of the computer system are acquired at the timing when any one of the system call monitoring means detects the predetermined system call sequence, recorded in association with the acquired time, and the process state is monitored. And a recording restart means for restarting the process using the recorded memory state from an OS other than the OS on which the process in which the failure is detected operates when a failure is detected,
The computer system characterized in that the predetermined system call sequence is a system call sequence indicating that an event that affects the integrity of the process is just before the occurrence. Calculator
System call monitoring means for monitoring a system call issued in a process running on the computer and detecting a system call string indicating that an event that affects the integrity of the process is just before the occurrence When,
When the system call monitoring unit acquires the memory state of the process at the timing when the predetermined system call sequence is detected, records the memory state in association with the acquired time, monitors the process state, and detects a failure. A program for functioning as recording restarting means for restarting the process using the recorded memory state.

Images