EP1782201A2 - Procede de gestion d'un processus logiciel, procede et systeme de redistribution ou de continuite de fonctionnement dans une architecture multi-ordinateurs - Google Patents

Procede de gestion d'un processus logiciel, procede et systeme de redistribution ou de continuite de fonctionnement dans une architecture multi-ordinateurs

Info

Publication number
EP1782201A2
EP1782201A2 EP05778898A EP05778898A EP1782201A2 EP 1782201 A2 EP1782201 A2 EP 1782201A2 EP 05778898 A EP05778898 A EP 05778898A EP 05778898 A EP05778898 A EP 05778898A EP 1782201 A2 EP1782201 A2 EP 1782201A2
Authority
EP
European Patent Office
Prior art keywords
application
processes
controller
state
execution
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP05778898A
Other languages
German (de)
English (en)
Inventor
Marc Vertes
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Meiosys SAS
Original Assignee
Meiosys SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Meiosys SAS filed Critical Meiosys SAS
Publication of EP1782201A2 publication Critical patent/EP1782201A2/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1479—Generic software techniques for error detection or fault masking
    • G06F11/1482—Generic software techniques for error detection or fault masking by means of middleware or OS functionality
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1415—Saving, restoring, recovering or retrying at system level
    • G06F11/1438—Restarting or rejuvenating
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2035—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant without idle spare hardware

Definitions

  • the present invention relates to a method for managing a software application operating in a multi-computer (cluster) architecture, for example for analyzing or modifying its execution environment, in the most transparent manner possible vis-à-vis -vis this application. It also relates to a method for modifying or adjusting the operation of such an application by using this operation management method to redistribute its processes within a cluster. This redistribution method can in particular be used to modify the distribution of the workload between different machines of a network, or to make the application more reliable by improving the continuity of operation. The invention also relates to a multi-computer system implementing this method of redistribution of operation.
  • the field of the invention is that of networks or computer clusters formed of several computers collaborating with one another. These clusters are used to run software applications that provide one or more services to users. Such an application can be mono ⁇ process or multi-process, and be executed on a single computer or distributed on several computers, for example in the form of a distributed application of MPI type ("Message Passing Interface").
  • MPI type Message Passing Interface
  • an application is run on a computer or group of computers in the cluster, called the primary or operational node, while the other computers in the cluster are called secondary nodes or " stand-by Colour
  • the exploitation of such clusters shows that there are reliability problems that may be due to hardware or operating system failures, human errors, or the failure of the applications themselves.
  • Additional libraries can also be integrated during compilation, to add these features permanently to the executable code.
  • Such libraries can even interpose between the calls provided in the application and the libraries of origins as described in patent FR 02/00398, for diverting these calls to a new library, editable running.
  • these methods require intervention at the stage of the compilation of the application, which is expensive and complex, may require intervention of the designer of the application and still be a source of errors or incompatibilities.
  • An object of the invention is then to allow a more complete management of an application process, more transparently for the operation of this application.
  • this objective is achieved with a method of managing a software application comprising at least a first software process, said target process, running on at least one computer and in a runtime environment comprising at least one execution memory space .
  • this method comprises an operation of injecting at least one executable instruction into the memory space of the target process, by at least a second software process, called a controller process, external to the application and able to act on the progress of the process target, this executable statement performing an analysis or modification of the execution environment of this target process.
  • the injection operation comprises steps of: interrupting the execution of the target process by the controller process;
  • this operation management method further comprises a combination of the following characteristics:
  • the step of interrupting the target process can be followed by at least one step of reading and saving instructions stored in the reassigned zone and / or the state of the execution context of the target process when it is interrupted.
  • the step of writing injected instructions may be preceded by a step of writing in the reassigned data area realizing an addressing correspondence between this reassigned zone and another determined memory space, called mapping zone.
  • the execution step of the injected instructions may be preceded by a step of writing in the reassigned data area constituting arguments of the injected instructions.
  • the execution step of the injected instructions may also be preceded by a step of modifying the execution context according to parameters corresponding to the injected instructions.
  • the execution step of the injected instructions may be followed by a step of reading data stored in the reassigned zone and / or reading the state of the execution context of the target process.
  • the step of writing injected instructions may comprise writing at least one execution interrupt instruction in the reassigned zone after the injected instructions.
  • Another object of the invention is to facilitate the implementation in the operation of an application, in the most transparent manner possible for this application, of functionalities allowing the analysis, the capture or the modification of the environment of this application or the resources it uses.
  • the invention proposes a method for managing the operation of a software application as above, carrying out an introspection operation of at least two introspected processes, each of these introspected processes using a first resource comprising itself. even a pointer designating a second resource itself having an attribute that is accessible to said process through said pointer, the method comprising the following steps:
  • the invention also proposes a method for managing the operation of a software application as above, performing a capture operation of the state of the target process, said captured process, and comprising steps of:
  • the operation management method may in particular carry out a state capture operation of at least two processes of this application, the interruption of these two processes occurring either simultaneously or at points of their respective processes of which one is calculated according to the other.
  • the capture operation may further comprise steps of: injection, by the controller process in the captured process of at least one system call instruction performing read in the inter-process agent of at least one communication data from another process of the application and not yet received by the process captured;
  • the capture operation may further include steps of:
  • the invention also proposes a method for managing the operation of a software application as above, carrying out a restore operation, by a controller process from data known as recovery data, the state of at least one software application process, called the recovery process.
  • the restore operation then includes steps of:
  • the restore operation also described above can also be combined with the following characteristics.
  • the restore operation may include in addition to a step of: injection, by the controller process in the captured process, of at least one system call instruction which, from the recovery data, writes the writing within the inter-process agent of at least one datum representing a datum of communication to the recovery process.
  • the restore operation may further include a step of: - injection, by the controller process into the recovery process at least one system call instruction creating or modifying, from the recovery data, at least one inheritance relationship of the recovery process with at least one other process of the application.
  • Another object of the invention is thus to be able to move the execution of all or part of this application from one hardware resource to another, for example from one computer to another or from one node to another.
  • the invention proposes using the above method to perform a method of replicating at least one process of the application, called the original process, into a clone process, comprising the following steps:
  • checkpoint data to restore at least one clone process to a state reproducing the state of the original process.
  • the invention also proposes using the above method to perform a method of redistributing all or part of a so-called redistributed software application, executed in a multi-computer architecture (cluster) and comprising at least a process, called the initial process, providing a data processing by being executed at a given moment on at least one computer of the cluster, called primary or operational node, other computers of said cluster being called secondary nodes, this redistribution method comprising the following steps: - replication of at least one initial process into at least one secondary process running on a secondary node;
  • Such a redistribution makes it possible in particular to transfer this or that computing task from one node to another within the cluster. It is thus possible to redistribute the workload of the different machines, to obtain a better balancing of this workload within the cluster.
  • the redistribution method further comprises the following steps: replication of all the processes executed by the operational node in one or more secondary processes executed on at least one secondary node;
  • the invention also proposes to use the above method to perform a method of suspending a software application comprising at least one process executed on at least one computer, this suspension method comprising the following steps:
  • checkpoint data to restore one or more clone processes in a state reproducing the state of the set of captured processes.
  • the restoration step can be carried out on the same machine or on another, at the chosen moment. It is thus possible to facilitate the maintenance or the replacement of a machine, in particular when it is not possible to transfer the application to another part of a cluster. It is also possible to facilitate the transfer of an application to one or more other machines, for example with which there is no direct digital communications.
  • Another object is to propose a method for achieving an improvement in the continuity of operation of a software application running in a multi-computer architecture.
  • This goal is achieved by a process for reliability of the operation of a software application, called a trusted application, executed in a multi-computer architecture (cluster) and providing a specific service, at least one process of this application being executed at a given moment. given on at least one computer of the cluster, called primary or operational node, other computers of said cluster being called secondary nodes.
  • This reliability process implements a management method described above to perform at least one capture operation and at least one restore operation, and comprises the following steps:
  • the operation management method according to the invention can associate, selectively or not, capture operations with restoration operations to achieve a holistic replication of the state of an application called original in a clone application.
  • the replication method described above is then implemented to replicate all the processes and resources of the original application as processes and resources of the clone application.
  • this method of continuity of operation can of course update or restore one or more processes clones after the detection of a failure rather than before, or achieve a combination of both.
  • the invention also proposes a method for making a trusted software application reliable, executed in a multi-computer architecture (cluster) and providing a determined service, at least one process of this application, said process being made reliable, being executed at at a given moment on at least one computer in the cluster, called the primary node or operational, other computers of said cluster being called secondary nodes, this reliability process comprising the following steps:
  • the invention also proposes a multi-computer system implementing the method according to the invention.
  • An advantage of using a different control process of the process to be managed, that is to say the target process, is in particular to be able to implement the operations necessary for the functionality of continuity or redistribution of operation in the form of operations external to the application, that is to say outside the memory space of the target process.
  • These external operations are, for example, checkpoint definitions, triggers for capturing or restoring states, analyzes or modifications of resource structures, or reads or writes data into these resources.
  • this access from the inside allows the management of a process not to depend on the functionality limits specific to these debuggers.
  • the present invention makes it possible not to be limited, through the list of "debug symbols" of the target application, to the functions already present in this target application.
  • system calls made by injection make it possible to use parameters stored in the registers, and at the top of the stack, as is the case with many debuggers.
  • this injection method also makes it possible to dispense with access permissions to certain resources such as the stack execution permission, which may exist in some operating systems such as SELinux, SUN-Solaris or OpenBSD.
  • controller and instruction injection makes it possible to perform a capture method of capturing a checkpoint or a restoration method that is simple and straightforward.
  • a basic demonstration program that provides these replication capabilities for a single process without files or connections can represent approximately 500 lines of C language programs.
  • the restricted and temporary aspect of the system call injection method makes it possible to insert only a few instructions in the memory space of the process to be managed and of which nothing remains in the end. operation. This therefore avoids "polluting" the target process, which is an advantage from the point of view of reliability and maintenance of the application.
  • the method according to the invention has the advantage of being usable both with a target application using static executable files, that is to say including all the necessary routines, that dynamic, that is to say doing calling subroutine libraries outside the application.
  • the method according to the invention allows a redistribution or continuity of operation by intervening little or no outside the field of work of the user.
  • the implementation of checkpointing and recovery operations in themselves require little or no system modification (kernel) or system resource additions (kernel modules).
  • kernel system modification
  • kernel modules system resource additions
  • controller process can perform a recovery of the state of a recovery process without having itself started the recovery process allows to work on an existing recovery process. This possibility allows the management of redistribution or continuity of operation, not to interfere with the starting modes of a target application or its processes, which facilitates for example the application of the invention to distributed applications ( MPI).
  • MPI distributed applications
  • FIG. 1a shows the organization of a cluster executing a software application, the operation of which is made reliable by a redistribution application implementing a method according to the invention to achieve a complete redistribution;
  • FIG. 1b represents the organization of a cluster executing a software application, whose operation is adjusted by a redistribution application implementing a method according to the invention to achieve a partial redistribution;
  • FIG. 2 is a symbolic diagram of the progress of a program instruction injection operation by a controller process within a target process
  • FIG. 3 is a symbolic diagram of the operation of an operation for capturing the state of a process
  • FIG. 4 is a symbolic diagram of the operation of a recovery operation of a recovery process
  • FIG. 5 is a diagram illustrating the structure of two processes using shared or separate file descriptors
  • FIG. 6 is a diagram illustrating the progress of a multi-process introspection method using an injection of system calls.
  • FIGS 1a and 1b are illustrated uses of a replication method according to the invention in a functional redistribution application.
  • This operation redistribution application is used to redistribute the operation of a software application, called a redistributed application, executed on an operational node OP of a multi-computer or cluster architecture.
  • a node can be a single computer within the cluster or include multiple computers working together within the cluster.
  • the redistributed application includes at least one process, referred to as the original PCA process, working in a runtime environment in which it accesses a number of resources of different types. Commonly, these resources comprise: an execution memory space allocated in the working memory of the node OP, and where the executed instructions constituting the process are stored; an execution context, including memory registers and different types of state resources such as flags, mutex, etc. ;
  • Some of the resources available to a process can be distributed across multiple computers or nodes, especially in the case of distributed applications, for example for variables stored in shared memory areas or as shared files or as shared files. external databases.
  • the operation redistribution application is executed on one or more computers of the cluster communicating with the operational node of the application and at least one secondary node SB.
  • This redistribution of operation is done by storing regularly or on an event, at a checkpoint, an instantaneous state of one or more original PCA processes of the redistributed application.
  • the redistribution application performs a checkpoint capture operation, according to a method described hereinafter.
  • this checkpoint capture operation uses a redistributed application operation management method, described hereinafter, implemented by a temporary PCl controller process acting on the original PCA process of the redistributed application.
  • the redistribution application stores a software object, called checkpoint state, in memory means within the cluster.
  • checkpoint state a software object
  • certain resources of the redistributed application such as databases or files, can also be saved or replicated over the water or in stages, according to known means. .
  • the redistribution application performs a complete redistribution of the redistributed application, i.e. all of its processes and the links that unite them.
  • such a complete redistribution can in particular be used to make the redistributed application reliable, by constituting a backup application, which will maintain a certain degree of reliability. continuity in the service provided in case of failure of the operational node OP.
  • the operation redistribution application uses a checkpoint state to perform one or more restores of the redistributed application in the form of at least one backup application, called recovery application.
  • a recovery application includes a clone process running on a secondary node SB of the cluster and resources ensuring a state corresponding to the state of the original PCA process when capturing this checkpoint.
  • This restoration can be done on a regular basis or on an event, and can include a complete start with creation of the clone process, also called recovery process, or restore by updating an already existing clone process.
  • the redistribution application performs an operation of updating the clone process from a checkpoint, according to a method described hereinafter.
  • this updating operation uses an operation management method, described hereinafter, implemented by a temporary PC2 controller process acting on the clone process of the system call injection recovery application. as described below.
  • the operation redistribution application In the event of a failure affecting the operation of the trusted application on the operational node, the operation redistribution application is notified by a monitoring or failure detection function, according to known means. The operation redistribution application then performs a service failover to the standby application, and the clone process then resumes the role that the original PCA process played before the failure.
  • the service redistribution application may also perform an update of the recovery application after the failure, or a complete start of this recovery application followed by an upgrade. day according to the method of the invention.
  • such a complete redistribution can be used also to completely move a application of one node to another, for example to release this node for a hardware intervention.
  • the redistribution application realizes a partial redistribution of the redistributed application, that is to say by a replication of only a part of its processes and the links which unite them between them, while updating the links that unite them to other processes.
  • the operation redistribution application When the operation redistribution application receives a partial redistribution command, it realizes a checkpoint state about the process (s) to replicate, or identifies a previously saved checkpoint state about those same processes. For each process, referred to as the original PCA process, to replicate, the operation redistribution application creates a clone process PCA 'within the SB to which the original PCA process is to be redistributed.
  • the operation redistribution application performs a restore of the clone process PCA 'in the state of the original PCA process at the time of establishment of the checkpoint.
  • This restoration also includes a restoration, between the various clone processes, of the state of the links which exist between their respective original processes. If the original PCA process has links to another PCB process that has not been replicated, a link in the same state will be created and restored between that other PCB process and the PCA clone process.
  • the redistribution operation application will also create for the PCB clone process a virtualized version of all or part of the resources used by the original PCA process, or a copy of these resources.
  • Such virtualization can be applied for example to process identifiers (PIDs), or file descriptor identities.
  • the functional redistribution application may then delete the original PCA process without disrupting the continuity of the redistributed application or the services provided.
  • Such partial redistribution can in particular be used to adjust the operation of the redistributed application, by moving certain processes to other nodes so as to modify the distribution of the workload within the cluster, for example in order to improve performances.
  • This workload can be, for example, computation, or file accesses, or network communications internal to the cluster or externally.
  • a partial redistribution can also be used to release a node or a communication line within the cluster, for example to perform interventions on the hardware that constitutes it.
  • FIG. 2 illustrates more specifically the above-mentioned operation management method.
  • This method is implemented by a controller process and applied to a process to be managed, or target process, on which it realizes a mechanism for injecting program instructions.
  • the vertical rectangle represents the execution memory ME containing the instructions executed by the target process
  • the group of rectangles on its right represents the working registers R used by this process
  • the triangle on its left represents the PE execution pointer of the process within the execution memory.
  • the controller process takes control of the target process, for example by an "attach” command based on the "ptrace” routine.
  • the controller process interrupts the execution of the target process, and defines a reassigned zone 2030, or "scratch area", within the execution memory of this target process.
  • the controller process then reads the contents of the reassigned zone SA, the position of the execution pointer PE, and the state of the working registers R, and makes a backup 204 of the initial state of these elements. .
  • the controller process checks 205 that the reassigned area SA is large enough to perform the following operations. In the opposite case, it can carry out 206 mapping of this zone according to known means, to make it correspond to another larger memory space, called mapping zone, determined outside the execution memory ME of target process. This mapping area can then be used by the target process in place of the reassigned zone. Then 207, the controller process writes the ID code corresponding to the program instructions to be injected within the reassigned zone SA, and writes a breakpoint instruction at the end of the reassigned zone SA.
  • the controller process can write in the reallocated area SA ARJ data corresponding to any arguments that must use UI instructions.
  • the controller process modifies the state of the working registers R to give them the RIJ values corresponding to the execution of the instructions to be injected IU.
  • the controller process will then set the execution pointer PE on the first IU instruction of the injected mechanism and start the execution of the target process.
  • the target process then executes the IU instructions of the injected mechanism, for example system calls performing an analysis or modification of the resource structure of the target process.
  • the execution of the injected mechanism may receive feedback data, which will be stored in the reassigned zone SA or in its work registers R, for example the responses returned by the operating system to the system calls included in the injected mechanism.
  • the execution pointer PE arrives at the previously written interrupt instruction 207, the target process is interrupted again and recalls the controller process.
  • the controller process will then collect the results of the execution of the injected mechanism, in the form of result data read in the reassigned area SA and in the work registers R, and save these results data independently of the environment of the process. execution of the target process.
  • the controller process uses the initial state data saved 204 previously to write in the reassigned area SA and the working registers R and return them to the state where they were during the initial interrupt 202.
  • the execution memory space is thus restored to the state where it was before the injection of the instruction ID.
  • the injection operation can thus be considered temporary or temporary, which avoids polluting the target process where the application that uses it.
  • the controller process can then reposition the PE execution pointer on the instruction which was initially the next to execute, and restart the target process. Once the process targets again in execution, the controller process releases it from its control, for example by a "detach” instruction or command, based on the "ptrace” routine in a similar way to the "attach” command.
  • FIG. 3 illustrates the use of the operation management method according to the invention to perform an operation of capturing the state of a process, referred to as the captured process, and of its execution environment, by a controller process.
  • the controller process first takes control of the captured process, for example by an "attach” instruction based on the "ptrace” routine.
  • the controller process can then interrupt the execution of the process captured in this step and suspend some or all of the resources it uses.
  • a next step 302 is to perform an introspection of the operating environment of the captured process to establish a list 303 resources of this runtime environment.
  • the controller process analyzes the structure of the resources to which it has access.
  • the controller process establishes a list of instructions to be injected into the process captured to access these resources, for example in the form of a list of 305 system calls and their settings.
  • the controller process injects each instruction or instruction group from this list and collects the result data, according to the operation management method described above. By this injection of system calls, the controller process obtains data 307 representing the structure of resources that were not directly accessible to it.
  • this step 306 implements a multi-process introspection method with injection of system instructions.
  • This method performs several injection operations coordinated with each other, applied to several target processes. Injection operations introduce changes in this resource through at least one of these target processes. The results of these operations are then compared with one another to obtain information on the mode of operation of the introspected resource.
  • the controller process can then capture 308 the contents of these same resources and save it 310 for constituting a checkpoint state 311, i.e., an image of the state of the captured process. So the instruction
  • system call injection phase 306 can also be used to obtain the content or status of certain resources by injecting the corresponding read instructions.
  • the process * takes control of a process by ptrace.
  • the process * is defined by its process id 7 ptrace (PTRACE_ATTACH, pid, 0, 0);
  • program instructions providing instruction injection for capturing the position of the write pointer of a file descriptor opened by the captured process.
  • ⁇ int file_pos PT_LSEEK (pid, fd, 0, SEEK_CUR); return file_pos;
  • Figures 5 and 6 illustrate an example of a multi-process introspection method, applied to the analysis of a file descriptor.
  • the multi-process introspection method is then used to determine whether two FDA and FDB file descriptors, used by two different PA and PB processes and pointing to FA and FB files, are separate or shared descriptors.
  • a PCl controller process injects a system call instruction within the first target process PA.
  • This system call performs a ptAO reading of the read / write pointer position of the FDA file descriptor of this first target process PA.
  • This PCl controller process injects system call instructions into the second PB target process.
  • one of these system calls first performs a ptBO reading of the position of the read / write pointer of the FDB file descriptor of this second target process PB.
  • step 503 another of these system calls, for example an "Iseek" instruction, then realizes a modification of the position of this same pointer.
  • the PCl controller process injects a system call instruction into the first target process PA.
  • This system call performs a new read ptAl of the read / write pointer position of the FDA file descriptor of this first target process
  • the controller PCl process compares the ptAO and ptAl values obtained by the two pointer position readings of the first descriptor FD1.
  • the PCl controller process then stores data representing this information.
  • the PCl controller process then injects a system call instruction into one of the two target processes, for example PB, to return the pointer to its initial position ptBO.
  • the PCl controller process then stores data representing this information.
  • the controller PCl process then injects a system call instruction within the second target process PB to return its pointer to its initial position ptBO.
  • the modified pointer is returned to its initial position, and the process is therefore transparent for both target processes.
  • FIG. 4 illustrates the use of the operation management method according to the invention to carry out an operation for updating or restoring a process, called the recovery process, and its execution environment, by a controller process .
  • This figure represents a restore operation, comprising a part 401, 402, 403 for creating the recovery process.
  • the controller process triggers this creation by initiating 401 a new process, called the recovery process, under its control (forking technique), then using a "ptrace (TRACEMEM, ...)" instruction before launching it. 'execution.
  • the recovery process then starts normally by loading 402 the various resources as in a conventional cold start. At this stage begins the actual process of updating the state of a recovery process, that is to say the method that can be used on an already existing recovery process.
  • this recovery process stops 404 immediately after loading, because of its launch mode, and reminds the controller process.
  • the controller process begins by taking control of the captured process 405, for example by an "attach" instruction based on the "ptrace" routine. The controller process then performs a selection and reading of data previously saved and constituting a checkpoint state. From the contents of this checkpoint, the controller process evaluates the structure and content changes to be made in the execution environment of the recovery process as it is to bring it to the state of selected resume point.
  • the controller processes them by itself.
  • the controller process prepares a list of system calls that it injects 408 into the recovery process, according to the operation management method of the invention.
  • This injection is used, for example, to modify the addressing and the mapping of the memory segments used, by injecting one or more mmap system calls.
  • the same principle is used for all or part of the system resources that must be recreated to arrive at a state identical to the selected checkpoint state.
  • system resources are for example resources of the type "file”, “socket”, “pipe”, “timer”, “terminal control”, etc.
  • controller process 409 writes these system resources according to the data of the checkpoint state, to bring the recovery process back to the state where the captured process was. when establishing the selected recovery bridge.
  • the controller process then raises 410 the execution of the recovery process and releases it 411 of its control, for example by a "detach” command, based on the "ptrace” routine in a similar way to the "attach” command.
  • the system call injection phase 408 can also be used to write the content or status of certain resources, by injecting the corresponding read instructions.
  • this restore operation Since it operates from a process external to the recovery process, this restore operation is much simpler and more efficient than if it were to be done by operations planned within the recovery process itself.
  • C instructions for a POSIX environment program instructions that perform an instruction injection to restore the position of the write pointer of a file descriptor opened by or for the process. of recovery.
  • establishing a checkpoint may require capturing the status of many of these processes.
  • the use of one or more control processes outside the processes to be captured is an advantage provided by the method according to the invention.
  • the operation redistribution application performs a capture operation according to the invention on several captured processes, so as to synchronize or coordinate the initial interruption 301 of each of the catching operations and the suspension of the resources concerned.
  • some data being transmitted between several processes can be "frozen" within the IPC interprocessor software mechanism that manages these transmissions, for example the "Inter Process Communication" software object in an environment of Unix type.
  • the operation redistribution application uses the operation management method according to the invention to inject into each of the interrupted processes the system calls to manage. these data being transmitted. For example, it may be to purge IPC queues (pipe) of unprocessed data as part of a process state capture operation at a checkpoint. or restore the same data in the case of a process update.
  • IPC queues pipe
  • the capture operation then further comprises an analysis and storage of all the communications data, or packets, which have been intended for it but do not have have been received.
  • this inter-process agent is managed by the system, for example in a kernel module for the Unix case, it is advantageous not to have to intervene in the system.
  • the PCl controller process uses the operation management method according to the invention to inject into the process being captured system calls that will request a reading of these communication data during transit. The controller process then retrieves this data and saves it within the checkpoint state.
  • the PC2 controller process In a recovery situation, when all recovery processes are suspended, the PC2 controller process also uses the management process according to the invention for injecting into each recovery process system calls that will write within the IPC interprocessing agent the packets in transit that had been stored in the checkpoint state.
  • some of these processes may have inheritance relationships between them. That is, a "child” process may have been created from a "parent” process, and inherit from that inheritance relationship certain features or resources of its operating environment, in particular of type "file descriptor".
  • the PCl controller process When capturing the processes of an application, the PCl controller process will use the management process according to the invention to inject into each captured process system calls that will analyze its possible inheritance relationships with one or more other processes. The results of these analyzes will then be saved within the current checkpoint state.
  • the PCl controller process will use the management process according to the invention to inject into each recovery process system calls that will recreate the same inheritance relations that had been stored in the state. point of recovery.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Retry When Errors Occur (AREA)
  • Stored Programmes (AREA)
  • Hardware Redundancy (AREA)

Abstract

La présente invention concerne un procédé de gestion d'une application logicielle fonctionnant dans une architecture multi-ordinateurs (cluster). Cette gestion s'applique par exemple à l'analyse ou la modification de son environnement d'exécution, d'une façon la plus transparente possible vis-à-vis de cette application. Cette gestion est appliquée à des opérations d'analyse, de capture et de restauration de l'état d'un ou plusieurs processus de l'application. Ces opérations utilisent un contrôleur externe à l'application qui réalise une injection d'instructions d'appels système à l'intérieur de la mémoire de travail du ou des processus à gérer.

Description

« Procédé de gestion d'un processus logiciel, procédé et système de redistribution ou de continuité de fonctionnement dans une architecture multi-ordinateurs »
La présente invention concerne un procédé de gestion d'une application logicielle fonctionnant dans une architecture multi-ordinateurs (cluster), par exemple d'analyse ou de modification de son environnement d'exécution, d'une façon la plus transparente possible vis-à-vis de cette application. Elle concerne également un procédé pour modifier ou ajuster le fonctionnement d'une telle application en utilisant ce procédé de gestion de fonctionnement pour réaliser une redistribution de ses processus au sein d'un cluster. Ce procédé de redistribution peut en particulier être utilisé pour modifier la répartition de la charge de travail entre différentes machines d'un réseau, ou pour fiabiliser l'application en en améliorant la continuité de fonctionnement. L'invention concerne également un système multi-ordinateurs mettant en œuvre ce procédé de redistribution de fonctionnement.
Le domaine de l'invention est celui des réseaux ou clusters d'ordinateurs formés de plusieurs ordinateurs collaborant entre eux. Ces clusters sont utilisés pour exécuter des applications logicielles apportant un ou des services à des utilisateurs. Une telle application peut être mono¬ processus ou multi-processus, et être exécutée sur un seul ordinateur ou distribuée sur plusieurs ordinateurs, par exemple sous la forme d'une application distribuée de type MPI (« Message Passing Interface »). A un instant donné, dans un contexte d'architecture redondante et communicante, une application est exécutée sur un ordinateur ou un groupe d'ordinateurs du cluster, appelé nœud primaire ou opérationnel, tandis que les autres ordinateurs du cluster sont appelés nœuds secondaires ou « stand-by ». Or, l'exploitation de tels clusters montre que se posent des problèmes de fiabilité qui peuvent être dus à des défaillances du matériel ou du système d'exploitation, à des erreurs humaines, ou à la défaillance des applications elles-mêmes.
Pour résoudre ces problèmes de fiabilité, il existe actuellement des mécanismes, dits de haute disponibilité, qui sont mis en œuvre sur la plupart des clusters actuels et qui sont basés sur un redémarrage automatique à froid de l'application sur un nœud de secours parmi l'un des nœuds secondaires du cluster.
Or, pour revenir à une situation proche de celle existant lors de la défaillance, ces mécanismes basés sur un redémarrage à froid présentent souvent une durée et une complexité de mise en œuvre importante, ce qui nuit à la bonne continuité du service fourni par l'application en cours d'exécution au moment de la défaillance.
Pour améliorer cette continuité, il est également connu, par exemple par le brevet FR 02/09855, de prévoir un ou plusieurs clones du nœud opérationnel, maintenus à jour périodiquement ou au fil de l'eau sur des nœuds secondaires.
De plus, au cours de l'exploitation de tels clusters, certaines ressources matérielles comme des ordinateurs ou des voies ou lignes de communication peuvent présenter une charge de travail trop importante, créant ainsi des goulots d'étranglement alors que d'autres sont sous- utilisées.
Pour améliorer les performances de l'application il est possible de réorganiser la répartition de l'application au sein du cluster. Toutefois, l'ensemble de ces techniques nécessite d'intervenir sur des processus en cours d'exécution, par des opérations de gestion de fonctionnement comme des opérations d'analyse, de capture ou de restauration des processus ou des ressources utilisées par l'application.
Or, de telles fonctionnalités ne sont pas forcément prévues dans l'application et les informations à relever ou à modifier ne sont pas toujours accessibles aux fonctions externes à l'application, par exemple au niveau du système d'exploitation.
Lorsque de telles fonctionnalités ne sont pas prévues directement à l'intérieur de l'application, il est alors coûteux et complexe voire impossible de les y intégrer ultérieurement, et cela nécessite souvent l'intervention du concepteur de l'application.
Pour implémenter de telles fonctionnalités sans intervenir directement dans la programmation de l'application, il est possible de modifier certaines instructions utilisées par l'application pour les enrichir des fonctionnalités nécessaires, ou d'ajouter ces fonctionnalités à divers stades de la compilation ou de l'exécution du code de l'application.
Pour cela, il est possible de modifier ou d'enrichir certains modules du système d'exploitation, par exemple au niveau du noyau (kernel). Toutefois, de telles modifications nuisent à l'homogénéité des différentes configurations utilisées au sein du réseau, et ne peuvent être facilement modifiées en cours d'exécution.
Des bibliothèques supplémentaires peuvent également être intégrées au cours de la compilation, pour ajouter ces fonctionnalités de façon permanente au code exécutable. De telles bibliothèques peuvent même réaliser une interposition entre les appels prévus dans l'application et les bibliothèques d'origines comme décrit dans le brevet FR 02/00398, permettant de détourner ces appels vers une nouvelle bibliothèque, modifiable en cours d'exécution. Toutefois ces méthodes nécessitent d'intervenir au stade de la compilation de l'application, ce qui est coûteux et complexe, peut nécessiter une intervention du concepteur de l'application et être malgré tout source d'erreurs ou d'incompatibilités.
Au sein d'une telle architecture, l'implémentation de certaines fonctionnalités de gestion d'un processus est donc délicate à réaliser sans modification ou intervention dans l'application ou dans le système ou les deux, ce qui est source de coût, de complexité et de risques d'erreurs.
Un objectif de l'invention est alors de permettre une gestion plus complète d'un processus applicatif, de façon plus transparente pour le fonctionnement de cette application.
Cet objectif est atteint avec un procédé de gestion d'une application logicielle comprenant au moins un premier processus logiciel, dit processus cible, s'exécutant sur au moins un ordinateur et dans un environnement d'exécution comprenant au moins un espace mémoire d'exécution. Selon l'invention, ce procédé comprend une opération d'injection d'au moins une instruction exécutable dans l'espace mémoire du processus cible, par au moins un deuxième processus logiciel, dit processus contrôleur, extérieur à l'application et apte à agir sur le déroulement du processus cible, cette instruction exécutable réalisant une analyse ou une modification de l'environnement d'exécution de ce processus cible.
Plus particulièrement, l'opération d'injection comprend des étapes de : - interruption de l'exécution du processus cible par le processus contrôleur ;
- écriture par le processus contrôleur dans une partie, dite zone réattribuée, de l'espace mémoire d'exécution du processus cible, d'instructions injectées réalisant le mécanisme d'analyse ou de modification ;
- exécution, par le processus cible, de ces instructions injectées ;
- restauration par le processus contrôleur, par écriture dans la zone réattribuée, des instructions du processus cible qui y étaient mémorisées avant l'interruption ; - exécution de la suite des instructions du processus cible.
Avantageusement, ce procédé de gestion de fonctionnement comprend en outre une combinaison des caractéristiques suivantes :
L'étape d'interruption du processus cible peut être suivie d'au moins une étape de lecture et sauvegarde des instructions mémorisées dans la zone réattribuée et/ou de l'état du contexte d'exécution du processus cible lors de son interruption.
L'étape d'écriture d'instructions injectées peut être précédée d'une étape d'écriture dans la zone réattribuée de données réalisant une correspondance par adressage entre cette zone réattribuée et un autre espace mémoire déterminé, dit zone de mapping.
L'étape d'exécution des instructions injectées peut être précédée d'une étape d'écriture dans la zone réattribuée de données constituant des arguments des instructions injectées.
L'étape d'exécution des instructions injectées peut également être précédée d'une étape de modification du contexte d'exécution en fonction de paramètres correspondant aux instructions injectées.
L'étape d'exécution des instructions injectées peut être suivie d'une étape de lecture de données mémorisées dans la zone réattribuée et/ou de lecture de l'état du contexte d'exécution du processus cible. L'étape d'écriture d'instructions injectées peut comprendre l'écriture d'au moins une instruction d'interruption d'exécution dans la zone réattribuée après les instructions injectées.
Un autre but de l'invention est de faciliter l'implémentation dans le fonctionnement une application, de façon la plus transparente possible pour cette application, de fonctionnalités permettant l'analyse, la capture ou la modification de l'environnement de cette application ou des ressources qu'elle utilise.
Pour cela, l'invention propose un procédé de gestion du fonctionnement d'une application logicielle tel que ci-dessus, réalisant une opération d'introspection d'au moins deux processus introspectés, chacun de ces processus introspectés utilisant une première ressource comportant elle-même un pointeur désignant une deuxième ressource comportant elle- même un attribut qui est accessible audit processus à travers ledit pointeur , le procédé comprenant les étapes suivantes :
- injection par le processus contrôleur dans chacun des deux processus introspectés d'au moins une instruction système réalisant une lecture initiale de la valeur de l'attribut de la deuxième ressource correspondant à chacun desdits processus introspectés ; - injection par le processus contrôleur dans l'un des deux processus introspectés, dit processus de test, d'au moins une instruction système réalisant une modification de la valeur de l'attribut de la deuxième ressource correspondant audit processus test ;
- injection par le processus contrôleur dans l'autre processus introspecté, dit processus témoin, d'au moins une instruction système réalisant une deuxième lecture de la valeur de l'attribut de la deuxième ressource correspondant audit processus témoin ;
- comparaison par le processus contrôleur de la valeur de deuxième lecture avec la valeur de lecture initiale dudit processus témoin ; - mémorisation par le processus contrôleur d'une donnée représentant le résultat de ladite comparaison et injection par le processus contrôleur dans le processus de test, d'au moins une instruction système réalisant une modification de la valeur de l'attribut de la deuxième ressource correspondant audit processus test, de façon à lui redonner sa valeur de lecture initiale.
Pour cela, l'invention propose également un procédé de gestion du fonctionnement d'une application logicielle tel que ci-dessus, réalisant une opération de capture de l'état du processus cible, dit processus capturé, et comprenant des étapes de :
- prise de contrôle du processus capturé par un processus contrôleur ;
- injection par le processus contrôleur dans le processus capturé d'au moins une instruction d'appel système réalisant une analyse de la structure de l'environnement d'exécution du processus capturé ;
- mémorisation ou transmission de données de résultat représentant le résultat de cette analyse et restauration de l'espace mémoire du processus capturé ;
- exécution de la suite des instructions du processus capturé. Lorsque l'application à gérer est de type multi-processus, multi¬ tâches ou « multi-threads », l'opération de capture décrite ci-dessus peut également se combiner avec les caractéristiques suivantes. Le procédé de gestion de fonctionnement peut en particulier réaliser une opération de capture de l'état d'au moins deux processus de cette application, l'interruption de ces deux processus se faisant soit de façon simultanée soit en des points de leurs déroulements respectifs dont l'un est calculé en fonction de l'autre.
Lorsque le processus capturé échange des données de communication avec au moins un autre processus par l'intermédiaire d'au moins un agent logiciel interprocessus extérieur à l'application, l'opération de capture peut comprendre en outre des étapes de : injection, par le processus contrôleur dans le processus capturé d'au moins une instruction d'appel système réalisant la lecture dans l'agent interprocessus d'au moins une donnée de communication en provenance d'un autre processus de l'application et non encore reçue par le processus capturé ;
- mémorisation ou transmission de cette donnée de communication en tant que donnée de résultat. Lorsque l'environnement d'exécution du processus capturé supporte la transmission de caractéristiques entre processus par des relations d'héritage, l'opération de capture peut comprendre en outre des étapes de :
- injection, par le processus contrôleur dans le processus capturé d'au moins une instruction d'appel système réalisant une analyse des relations d'héritage du processus capturé avec au moins un autre processus de l'application ;
- mémorisation ou transmission de données de résultat représentant les relations d'héritage du processus capturé. Dans le même esprit, l'invention propose également un procédé de gestion de fonctionnement d'une application logicielle tel que ci-dessus, réalisant une opération de restauration, par un processus contrôleur à partir de données dites de reprise, de l'état d'au moins un processus d'application logicielle, dit processus de reprise. L'opération de restauration comprend alors des étapes de :
- interruption de l'exécution du processus de reprise par le processus contrôleur ;
- injection par le processus contrôleur dans le processus de reprise d'au moins une instruction d'appel système créant ou modifiant la structure d'au moins un objet logiciel appartenant à l'environnement d'exécution du processus de reprise, en fonction des données de reprises ;
- écriture, à partir des données de reprise, de l'espace mémoire d'exécution du processus de reprise ; - lancement du processus de reprise et exécution de la suite de ses instructions.
Lorsque l'application à gérer est de type multi-processus, multi¬ tâches ou multi-threads, l'opération de restauration également décrite ci- dessus peut également se combiner avec les caractéristiques suivantes. Lorsque l'environnement d'exécution du processus de reprise supporte ou utilise l'échange de données de communication entre plusieurs processus par l'intermédiaire d'au moins un agent logiciel interprocessus extérieur à l'application, l'opération de restauration peut comprendre en outre une étape de : - injection, par le processus contrôleur dans le processus capturé d'au moins une instruction d'appel système réalisant, à partir des données de reprise, l'écriture au sein de l'agent interprocessus d'au moins une donnée représentant une donnée de communication à destination du processus de reprise.
Lorsque l'environnement d'exécution du processus de reprise supporte la transmission de caractéristiques entre processus par des relations d'héritage, l'opération de restauration peut comprendre en outre une étape de : - injection, par le processus contrôleur dans le processus de reprise d'au moins une instruction d'appel système créant ou modifiant, à partir des données de reprise, au moins une relations d'héritage du processus de reprise avec au moins un autre processus de l'application. Une telle implémentation de fonctionnalités de gestion d'un processus d'une application permet en particulier d'intervenir sur le fonctionnement de cette application et des services qu'elle produit, à moindre coût et en diminuant la complexité et le risque d'erreurs.
Or, pour gérer le fonctionnement d'une application, il est utile de mieux gérer la façon dont une application utilise des ressources matérielles au sein d'un cluster, tout en limitant les interventions à l'intérieur du fonctionnement d'une application et les risques et complexités que cela comporte.
Un autre but de l'invention est ainsi de pouvoir déplacer l'exécution de tout ou partie de cette application d'une ressource matérielle à une autre, par exemple d'un ordinateur à l'autre ou d'un nœud à un autre.
Pour cela l'invention propose d'utiliser le procédé ci-dessus pour réaliser un procédé de réplication d'au moins un processus de l'application, dit processus original, en un processus clone, comprenant les étapes suivantes :
- capture de l'état du processus original par un procédé selon l'une des revendications 2 à 6 ; - utilisation de données de résultat, issues de la capture, pour mémoriser un objet logiciel appelé point de reprise, représentant un état de ce processus original en un point de son exécution ;
- utilisation de données du point de reprise pour restaurer au moins un processus clone dans un état reproduisant l'état du processus original.
Dans le même esprit, l'invention propose également d'utiliser le procédé ci-dessus pour réaliser un procédé de redistribution de tout ou partie d'une application logicielle dite redistribuée, exécutée dans une architecture multi-ordinateurs (cluster) et comprenant au moins un processus, dit processus initial, fournissant un traitement de données en étant exécuté à un instant donné sur au moins un ordinateur du cluster, appelé nœud primaire ou opérationnel, d'autres ordinateurs dudit cluster étant appelés nœuds secondaires, ce procédé de redistribution comprenant les étapes suivantes : - réplication d'au moins un processus initial en au moins un processus secondaire exécuté sur un nœud secondaire ;
- basculement de tout ou partie du traitement de données du processus initial vers au moins un processus secondaire.
Une telle redistribution permet en particulier de transférer telle ou telle tâche de calcul d'un nœud à l'autre au sein du cluster. Il est ainsi possible de redistribuer la charge de travail des différentes machines, pour obtenir un meilleur équilibrage de cette charge de travail au sein du cluster.
Il est également possible de déplacer certains processus sur des machines plus proches des ressources qu'utilisent ces processus ou disposant de meilleures communications, par exemple pour réduire les temps de transmission entre certains processus et les bases de données qu'ils utilisent.
Selon une particularité, le procédé de redistribution comprend en outre les étapes suivantes : - réplication de tous les processus exécutés par le nœud opérationnel en un ou plusieurs processus secondaires exécutés sur au moins un nœud secondaire ;
- basculement de la totalité des traitements de données desdits processus vers au moins un desdits processus secondaires. II est ainsi possible de déplacer tous les processus utilisés par un matériel déterminé. Cela permet en particulier rendre l'application indépendante de ce matériel, par exemple dans le cas d'un ordinateur devant éteint pour entretien ou remplacement. Dans un but similaire, l'invention propose également d'utiliser le procédé ci-dessus pour réaliser un procédé de suspension d'une application logicielle comprenant au moins un processus exécuté sur au moins un ordinateur, ce procédé de suspension comprenant les étapes suivantes :
- capture de l'état de l'ensemble des processus de l'application, par un procédé selon l'une des revendications précédentes 3 à 5 ;
- utilisation de données de résultat, issues de la capture, pour mémoriser un objet logiciel appelé point de reprise, représentant un état de cette application en un point de son exécution ;
- utilisation de données du point de reprise pour restaurer un ou plusieurs processus clones dans un état reproduisant l'état de l'ensemble des processus capturés.
Il est ainsi possible de sauvegarder dans des moyens de mémorisation l'ensemble d'une application dans son état à un moment donné. Une telle sauvegarde peut alors être conservée et stockée, par exemple à titre de témoignage ou de sécurité.
L'étape de restauration peut s'effectuer sur une même machine ou sur une autre, au moment choisi. Il est ainsi possible de faciliter la maintenance ou le remplacement d'une machine, en particulier lorsqu'il n'est pas possible de transférer l'application dans une autre partie d'un cluster. Il est également de possible ainsi de faciliter le transfert d'une application vers une ou plusieurs autres machines, par exemple avec lesquelles il n'y a pas de communications numériques directes.
Un autre but est de proposer un procédé pour réaliser une amélioration de la continuité de fonctionnement d'une application logicielle s'exécutant dans une architecture multi-ordinateurs.
Ce but est atteint par un procédé de fiabilisation du fonctionnement d'une application logicielle, dite application fiabilisée, exécutée dans une architecture multi-ordinateurs (cluster) et fournissant un service déterminé, au moins un processus de cette application étant exécuté à un instant donné sur au moins un ordinateur du cluster, appelé nœud primaire ou opérationnel, d'autres ordinateurs dudit cluster étant appelés nœuds secondaires. Ce procédé de fiabilisation met en œuvre un procédé de gestion décrit ci-dessus pour réaliser au moins une opération de capture et au moins une opération de restauration, et comprend les étapes suivantes :
- capture par au moins un processus contrôleur de l'état de l'ensemble des processus de cette application fiabilisée ;
- utilisation de données de résultat, issues de la capture, pour mémoriser un objet logiciel appelé point de reprise, représentant un état de cette application fiabilisée en un point de son exécution ;
- détection au sein du nœud opérationnel d'une défaillance matérielle ou logicielle affectant le fonctionnement de l'application fiabilisée ;
- utilisation de tout ou partie des données du point de reprise pour restaurer, sur au moins un nœud secondaire, un ou plusieurs processus d'une application de secours en un état reproduisant l'état de l'ensemble des processus de l'application fiabilisée ;
- basculement de tout ou partie du service vers l'application de secours d'au moins l'un desdits noeuds secondaires.
Plus particulièrement, le procédé de gestion de fonctionnement selon l'invention peut associer, sélectivement ou non, des opérations de capture à des opérations de restauration pour réaliser une réplication holistique de l'état d'une application dite originale en une application clone. Le procédé de réplication décrit ci-dessus est alors mis en œuvre pour répliquer l'ensemble des processus et ressources de l'application originale en tant que processus et ressources de l'application clone.
Selon le même concept inventif, ce procédé de continuité de fonctionnement peut bien sûr mettre à jour ou restaurer un ou plusieurs processus clones après la détection d'une défaillance plutôt qu'avant, ou réaliser une combinaison des deux. Ainsi, l'invention propose également un procédé de fiabilisation d'une application logicielle dite fiabilisée, exécutée dans une architecture multi- ordinateurs (cluster) et fournissant un service déterminé, au moins un processus de cette application, dit processus fiabilisé, étant exécuté à un instant donné sur au moins un ordinateur du cluster, appelé nœud primaire ou opérationnel, d'autres ordinateurs dudit cluster étant appelés nœuds secondaires, ce procédé de fiabilisation comprenant les étapes suivantes :
- mise en œuvre d'un procédé de réplication holistique pour répliquer, sur au moins un nœud secondaire, une application de secours dans un état identique à celui de l'application fiabilisée ;
- détection au sein du nœud opérationnel d'une défaillance matérielle ou logicielle affectant le fonctionnement de l'application fiabilisée ;
- basculement de tout ou partie du service vers ladite application de secours d'au moins un des nœuds secondaires. L'invention propose également un système multi-ordinateurs mettant en œuvre le procédé selon l'invention.
Un avantage de l'utilisation d'un processus contrôleur différent du processus à gérer, c'est-à-dire du processus cible, est en particulier de pouvoir implémenter les opérations nécessaires aux fonctionnalités de continuité ou de redistribution de fonctionnement sous la forme d'opérations externes à l'application, c'est-à-dire à l'extérieur de l'espace mémoire du processus cible. Ces opérations externes sont par exemple des définitions de points de reprise, des déclenchements de captures ou de restauration d'états, des analyses ou modifications de structures de ressources, ou des lectures ou écritures de données dans ces ressources.
Ces calculs et opérations représentent en effet un certain volume de calcul dont seule une petite partie a besoin d'être exécutée depuis le processus cible. Il est donc avantageux d'injecter cette petite partie tout en réalisant le reste de la gestion de la redistribution ou de la continuité de fonctionnement en dehors de l'application devant être redistribuée ou fiabilisée. Cela permet au processus cible, donc à l'ensemble de l'application cible, de rester inchangé avant et après une opération de capture lors d'un point de reprise (checkpointing) ou de restauration (par démarrage ou mise à jour d'un clone) Combiné avec la gestion par un contrôleur extérieur à l'application, le fait d'utiliser une méthode d'implémentation par injection de code permet ainsi d'accéder à des fonctionnalités systèmes de l'intérieur de l'application pour les tâches qui le réclament, sans intervenir dans l'application. Comparé aux méthodes d'intervention externe utilisées par les programmes de mise au point (ou débugueurs), par exemple « GDB », cet accès de l'intérieur permet à la gestion d'un processus de ne pas dépendre des limites de fonctionnalités propres à ces débugueurs. Par exemple, la présente invention permet de n'être pas limité, à travers la liste de « symboles de debug » de l'application cible, aux fonctions déjà présentes dans cette application cible.
De plus, les appels systèmes réalisés par injection permettent d'utiliser des paramètres mémorisés dans les registres, et au sommet de la pile (stack) comme c'est le cas de nombreux débugueurs. Ainsi, cette méthode par injection permet également de s'affranchir des autorisations d'accès à certaines ressources comme la pile exécutable (stack exécution permission), qui peuvent exister dans certains systèmes d'exploitation comme SELinux, SUN-Solaris ou OpenBSD.
Cette combinaison de contrôleur et d'injection d'instructions permet de réaliser un procédé de déclenchement capture d'un point de reprise ou un procédé de restauration qui soit simple et direct. A titre d'ordre de grandeur, un programme basique de démonstration réalisant ces fonctionnalités de réplication pour un processus unique sans fichiers ni connexions peut représenter environ 500 lignes de programmes en langage C.
Par ailleurs, l'aspect restreint et temporaire de la méthode d'injection d'appels systèmes (system call injection) permet de n'insérer que peu d'instructions dans l'espace mémoire du processus à gérer et dont rien ne subsiste en fin d'opération. Cela permet donc d'éviter de « polluer » le processus cible, ce qui est un avantage du point de vue de la fiabilité comme de la maintenance de l'application.
Le procédé selon l'invention présente l'avantage d'être utilisable aussi bien avec une application cible utilisant des fichiers exécutables statiques, c'est-à-dire comprenant toutes les routines nécessaires, que dynamiques, c'est-à-dire faisant appel à des bibliothèques de sous-programmes à l'extérieur de l'application.
Par ailleurs, le procédé selon l'invention permet de réaliser une redistribution ou une continuité de fonctionnement en intervenant peu ou pas en dehors du domaine de travail de l'utilisateur. En particulier, l'implémentation des opérations de capture de point de reprise (checkpointing) et de restauration en elles-mêmes ne nécessitent que peu ou pas de modification du système (kernel) ou d'ajout de ressources systèmes (kernel modules). En évitant d'intervenir dans le système ou le noyau des nœuds concernés, cet aspect permet entre autres de minimiser les besoins en spécialistes systèmes, et d'homogénéiser les configurations systèmes installées sur les différents ordinateurs du cluster.
De plus, le fait que le processus contrôleur puisse effectuer une restauration de l'état d'un processus de reprise sans avoir réalisé lui-même le démarrage de ce processus de reprise permet de travailler sur un processus de reprise existant. Cette possibilité permet à la gestion de redistribution ou de continuité de fonctionnement, de ne pas interférer avec les modes de démarrage d'une application cible ou de ses processus, ce qui facilite par exemple l'application de l'invention à des applications distribuées (MPI).
D'autres particularités et avantages de l'invention ressortiront de la description détaillée d'un mode de mise en œuvre nullement limitatif, et des dessins annexés sur lesquels :
- la figure la représente l'organisation d'un cluster exécutant une application logicielle, dont le fonctionnement est fiabilisé par une application de redistribution mettant en œuvre un procédé selon l'invention pour réaliser une redistribution complète ;
- la figure Ib représente l'organisation d'un cluster exécutant une application logicielle, dont le fonctionnement est ajusté par une application de redistribution mettant en œuvre un procédé selon l'invention pour réaliser une redistribution partielle ;
- la figure 2 est un schéma symbolique du déroulement d'une opération d'injection d'instructions de programme par un processus contrôleur au sein d'un processus cible ; - la figure 3 est un schéma symbolique du fonctionnement d'une opération de capture de l'état d'un processus ;
- la figure 4 est un schéma symbolique du fonctionnement d'une opération de restauration d'un processus de reprise ; - la figure 5 est un schéma illustrant la structure de deux processus utilisant des descripteurs de fichiers partagés ou séparés ;
- la figure 6 est un schéma illustrant le déroulement d'un procédé d'introspection multi-processus utilisant une injection d'appels systèmes.
Dans la suite de la description, des exemples de commandes ou d'instructions utilisées pour réaliser le procédé selon l'invention sont présentés en utilisant le langage C et pour un environnement ou système d'exploitation de type Unix ou dérivés, en particulier POSIX. D'autres langages ou environnements systèmes peuvent bien sûr être utilisés pour implémenter l'invention.
En figures la et Ib sont illustrées des utilisations d'un procédé de réplication selon l'invention dans une application de redistribution de fonctionnement. Cette application de redistribution de fonctionnement est utilisée pour redistribuer le fonctionnement d'une application logicielle, dite application redistribuée, exécutée sur un nœud opérationnel OP d'une architecture multi-ordinateurs ou cluster. Un tel nœud peut être un ordinateur unique au sein du cluster ou comprendre plusieurs ordinateurs travaillant ensemble au sein du cluster. L'application redistribuée comprend au moins un processus, dit processus original PCA, travaillant dans un environnement d'exécution dans lequel il accède à un certain nombre de ressources de différents types. De façon courante, ces ressources comprennent : un espace mémoire d'exécution alloué dans la mémoire de travail du nœud OP, et où mémorisées les instructions exécutées constituant le processus ; un contexte d'exécution, incluant des registres mémoires et différents types de ressources d'état telles que flags, mutex, etc. ;
- des zones mémoires I/O (Input/Output) utilisées par l'ordinateur pour gérer les entrées et sorties avec l'utilisateur ou d'autres intervenants matériels ou logiciels ;
- des données mémorisées, par exemple des variables gérées par le processus ou des fichiers de données dont certaines peuvent être partagées avec d'autres applications non représentées communiquant avec l'application redistribuée.
Parmi les ressources accessibles à un processus, certaines peuvent se trouver réparties sur plusieurs ordinateurs ou plusieurs nœuds, en particulier dans le cas d'applications distribuées, par exemple pour des variables mémorisées dans des zones de mémoire partagée ou sous forme de fichiers partagés ou de bases de données extérieures.
L'application de redistribution de fonctionnement est exécutée sur un ou plusieurs ordinateurs du cluster communiquant avec le nœud opérationnel de l'application et au moins un nœud secondaire SB. Cette redistribution de fonctionnement se fait en mémorisant de façon régulière ou sur événement, en un point de reprise (« checkpoint »), un état instantané d'un ou plusieurs processus originaux PCA de l'application redistribuée. Lors du déclenchement d'un point de reprise, l'application de redistribution réalise une opération de capture de point de reprise, selon un procédé décrit ci-après. Selon l'invention, cette opération de capture de point de reprise, utilise un procédé de gestion de fonctionnement de l'application redistribuée, décrit ci-après, mis en œuvre par un processus contrôleur PCl temporaire agissant sur le processus original PCA de l'application redistribuée.
A l'issue de cette capture de point de reprise, l'application de redistribution mémorise un objet logiciel, dit état de point de reprise, dans des moyens de mémoire au sein du cluster. En plus de l'opération de capture selon l'invention, certaines ressources de l'application redistribuée, comme des bases de données ou des fichiers, peuvent également être sauvegardées ou répliquées au fil de l'eau ou par étapes, selon des moyens connus.
Dans un mode de réalisation, l'application de redistribution réalise une redistribution complète de l'application redistribuée, c'est-à-dire de l'ensemble de ses processus et des liens qui les unissent.
Ainsi qu'illustré en figure la, une telle redistribution complète peut en particulier être utilisée pour fiabiliser l'application redistribuée, en constituant une application de secours, qui maintiendra une certaine continuité dans le service fourni en cas de défaillance du nœud opérationnel OP.
Pour cela, l'application de redistribution de fonctionnement utilise un état de point de reprise pour effectuer une ou plusieurs restaurations de l'application redistribuée sous la forme d'au moins une application de secours, dite application de reprise. Une telle application de reprise comprend un processus clone exécuté sur un nœud secondaire SB du cluster et des ressources lui assurant un état correspondant à l'état du processus original PCA lors de la capture de ce point de reprise. Cette restauration peut se faire de façon régulière ou sur événement, et peut comprendre un démarrage complet avec création du processus clone, également appelé processus de reprise, ou effectuer une restauration par mise à jour d'un processus clone déjà existant.
Lors de cette restauration, l'application de redistribution réalise une opération de mise à jour du processus clone à partir d'un point de reprise, selon un procédé décrit ci-après. Selon l'invention, cette opération de mise à jour utilise un procédé de gestion de fonctionnement, décrit ci-après, mis en œuvre par un processus contrôleur PC2 temporaire agissant sur le processus clone de l'application de reprise par injection d'appels système, comme décrit ci-après.
En cas de défaillance affectant le fonctionnement, sur le nœud opérationnel, de l'application fiabilisée, l'application de redistribution de fonctionnement en est avertie par une fonction de surveillance ou de détection de défaillance, selon des moyens connus. L'application de redistribution de fonctionnement effectue alors un basculement de service vers l'application de secours, et le processus clone reprend alors le rôle que jouait le processus original PCA avant la défaillance.
Dans d'autres modes de réalisation, non représentés, l'application de redistribution de service peut également réaliser une mise à jour de l'application de reprise après la défaillance, ou un démarrage complet de cette application de reprise suivi d'une mise à jour selon le procédé de l'invention.
Dans d'autres particularités non illustrées ici, une telle redistribution complète peut être utilisée également pour déplacer complètement une application d'un nœud à un autre, par exemple pour libérer ce nœud pour une intervention matérielle.
En conservant les données de l'état de point de reprise un certain temps avant de restaurer l'application de reprise, on peut également réaliser un archivage de l'application redistribuée, ou une suspension de cette application par exemple pendant le temps d'une intervention matérielle sur le nœud opérationnel. En mémorisant les données de l'état de point de reprise sur un support transportable, il est également possible de déplacer cette application vers un autre ordinateur ou un autre cluster, sans nécessité d'une liaison informatique.
Dans un mode de réalisation illustré en figure Ib, l'application de redistribution réalise une redistribution partielle de l'application redistribuée, c'est-à-dire par une réplication d'une partie seulement de ses processus et des liens qui les unissent entre eux, tout en réactualisant les liens qui les unissent aux autres processus.
Lorsque l'application de redistribution de fonctionnement reçoit une commande de redistribution partielle, elle réalise un état de point de reprise portant sur le ou les processus à répliquer, ou identifie un état de point de reprise déjà mémorisé portant sur ces mêmes processus. Pour chaque processus, dit processus original PCA, à répliquer, l'application de redistribution de fonctionnement crée un processus clone PCA' au sein du nœud SB vers lequel doit être redistribué le processus original PCA.
A partir de cet état de point de reprise, l'application de redistribution de fonctionnement effectue une restauration du processus clone PCA' dans l'état du processus original PCA au moment de l'établissement du point de reprise. Cette restauration comprend également une restauration, entre les différents processus clones, de l'état des liens qui existent entre leurs processus originaux respectifs. Si le processus original PCA comporte des liens avec un autre processus PCB qui n'a pas été répliqué, un lien dans le même état sera créé et restauré entre cet autre processus PCB et le processus clone PCA'.
De façon à permettre à l'application redistribué de continuer à fonctionner correctement, l'application de redistribution de fonctionnement va également créer pour le processus clone PCB une version virtualisée de tout ou partie des ressources utilisées par le processus original PCA, ou d'une copie de ces ressources. Une telle virtualisation peut s'appliquer par exemple à des identificateurs de processus (PID), ou à des identités de descripteurs de fichiers.
Selon les besoins, l'application de redistribution de fonctionnement pourra alors supprimer le processus original PCA sans interrompre la continuité de fonctionnement de l'application redistribuée ni les services fournis. Une telle redistribution partielle peut en particulier être utilisée pour ajuster le fonctionnement de l'application redistribuée, en déplaçant certains processus vers d'autres nœuds de façon à modifier la répartition de la charge de travail au sein du cluster, par exemple en vue d'améliorer les performances. Cette charge de travail peut être par exemple du calcul, ou des accès fichiers, ou des communications réseau internes au cluster ou avec l'extérieur. Une redistribution partielle peut aussi être utilisée pour libérer un nœud ou une ligne de communication au sein du cluster, par exemple pour effectuer des interventions sur le matériel qui le constitue.
La figure 2 illustre plus précisément le procédé de gestion de fonctionnement cité ci-dessus.
Ce procédé est mis en œuvre par un processus contrôleur et appliqué sur un processus à gérer, ou processus cible, sur lequel il réalise un mécanisme d'injection d'instructions de programme. Sur cette figure, en regard de certaines étapes ou groupes d'étapes, sont illustrées graphiquement certaines opérations réalisées par l'étape concernée : le rectangle vertical représente la mémoire d'exécution ME contenant les instructions exécutées par le processus cible, le groupe de rectangles sur sa droite représente les registres de travail R utilisés par ce processus, et le triangle sur sa gauche représente le pointeur d'exécution PE du processus au sein de la mémoire d'exécution.
Dans la première étape 201 illustrée, le processus contrôleur prend le contrôle du processus cible, par exemple par une commande « attach » basée sur la routine « ptrace ». En une étape 202, le processus contrôleur interromps l'exécution du processus cible, et défini une zone réattribuée 2030, ou « scratch area », au sein de la mémoire d'exécution de ce processus cible.
Le processus contrôleur réalise alors 203 une lecture du contenu de la zone réattribuée SA, de la position du pointeur d'exécution PE, et de l'état des registres de travail R, et réalise une sauvegarde 204 de l'état initial de ces éléments.
Le processus contrôleur vérifie 205 que la zone réattribuée SA est suffisamment grande pour réaliser les opérations suivantes. Dans le cas contraire, il peut effectuer 206 un adressage (mapping) de cette zone selon des moyens connus, pour la faire correspondre à un autre espace mémoire plus important, dit zone de mapping, déterminé en dehors de la mémoire d'exécution ME du processus cible. Cette zone de mapping peut alors être utilisée par le processus cible en lieu et place de la zone réattribuée. Ensuite 207, le processus contrôleur écrit à l'intérieur de la zone réattribuée SA le code ID correspondant aux instructions de programme à injecter, et écrit une instruction d'interruption (breakpoint) à la fin de la zone réattribuée SA.
Ensuite 208, le processus contrôleur peut écrire dans la zone réattribuée SA des données ARJ correspondant aux éventuels arguments que doivent utiliser les instructions IU.
Ensuite 209, le processus contrôleur modifie l'état des registres de travail R pour leur donner les valeurs RIJ correspondant à l'exécution des instructions à injecter IU. Le processus contrôleur va alors 210 positionner le pointeur d'exécution PE sur la première instruction IU du mécanisme injecté et lancer l'exécution du processus cible.
Le processus cible exécute alors 211 les instructions IU du mécanisme injecté, par exemple des appels système réalisant une analyse ou une modification de la structure des ressources du processus cible. Selon sa nature, l'exécution du mécanisme injecté peut recevoir des données en retour, qui seront mémorisées dans la zone réattribuée SA ou dans ses registres de travail R, par exemple les réponses retournées par le système d'exploitation aux appels système compris dans le mécanisme injecté. Lorsque 212 le pointeur d'exécution PE arrive à l'instruction d'interruption écrite précédemment 207, le processus cible s'interromps à nouveau et rappelle le processus contrôleur.
Le processus contrôleur va alors 213 recueillir les résultats de l'exécution du mécanisme injecté, sous la forme de données de résultat lues dans la zone réattribuée SA et dans les registres de travail R, et sauvegarder ces données de résultats indépendamment de l'environnement d'exécution du processus cible.
Ensuite 241, le processus contrôleur utilise les données d'état initial sauvegardées 204 précédemment pour écrire dans la zone réattribuée SA et les registres de travail R et les remettre dans l'état où ils étaient lors de l'interruption initiale 202.
L'espace mémoire d'exécution est ainsi restauré dans l'état où il se trouvait avant l'injection des instruction ID. L'opération d'injection peut ainsi être considérée comme provisoire ou temporaire, ce qui évite de polluer le processus cible où l'application qui l'utilise.
Le processus contrôleur peut alors 215 repositionner le pointeur d'exécution PE sur l'instruction ce qui était initialement la prochaine à exécuter, et relancer le processus cible. Une fois le processus cible à nouveau en exécution, le processus contrôleur le libère de son contrôle, par exemple par une instruction ou une commande « detach », basée sur la routine « ptrace » de façon similaire à la commande « attach ».
La figure 3 illustre l'utilisation du procédé de gestion de fonctionnement selon l'invention pour réaliser une opération de capture de l'état d'un processus, dit processus capturé, et de son environnement d'exécution, par un processus contrôleur.
Dans la première étape représentée 301, le processus contrôleur commence par prendre le contrôle du processus capturé, par exemple par une instruction « attach » basée sur la routine « ptrace ». Le processus contrôleur peut alors interrompre l'exécution du processus capturé lors de cette étape et suspendre tout ou partie des ressources qu'il utilise.
Une étape suivante 302 consiste à réaliser une introspection de l'environnement d'exploitation du processus capturé pour établir une liste 303 des ressources de cet environnement d'exécution. Le processus contrôleur analyse la structure des ressources auxquelles il a accès.
La plupart de ces ressources sont directement accessibles par le processus contrôleur, par exemple par l'instruction de pseudo système de fichiers « /proc ».
Ainsi, l'instruction
« /proc/pid/fd » : fournit la liste des descripteurs de fichiers (fd) actuellement ouverts donc à sauvegarder, pour le processus concerné (pid).
« /proc/pid/maps » : fournit l'organisation et l'adressage des segments de mémoire utilisés ;
Une fois qu'il a identifié 304 les ressources qui ne lui sont pas directement accessibles, le processus contrôleur établit une liste d'instructions à injecter dans le processus capturé pour accéder à ces ressources, par exemple sous la forme d'une liste d'appels système 305 et de leurs paramètres.
En une étape 306 récursive, le processus contrôleur injecte chaque instruction ou groupe d'instruction de cette liste et en recueille les données de résultats, selon le procédé de gestion de fonctionnement décrit plus haut. Par cette injection d'appels système, le processus contrôleur obtient des données 307 représentant la structure des ressources qui ne lui étaient pas directement accessibles.
Pour l'introspection de certaines ressources dont la structure n'est pas directement accessible par un appel système au sein d'un seul processus cible, cette étape 306 met en œuvre un procédé d'introspection multi-processus avec injection d'instructions systèmes. Ce procédé réalise plusieurs opérations d'injection coordonnées entre elles, appliquées à plusieurs processus cibles. Les opérations d'injections introduisent des modifications dans cette ressource à travers au moins l'un de ces processus cibles. Les résultats de ces opérations sont alors comparés entre eux pour obtenir une information portant sur le mode de fonctionnement de la ressource introspectée.
A partir de la structure obtenue par introspection directe 302 ou par injection d'appels système 306, le processus contrôleur peut alors capturer 308 le contenu de ces même ressources et le sauvegarder 310 pour constituer un état de point de reprise 311, c'est-à-dire une image de l'état du processus capturé. Ainsi, l'instruction
« /proc/pid/mem » permet de lire le contenu de l'espace mémoire sous la forme de fichier en accès lecture.
« ptrace(PT_GETREGS,...) » permet d'accéder aux registres de travail Le processus contrôleur relance alors l'exécution du processus capturé et le libère 312 de son contrôle, par exemple par une commande « detach », basée sur la routine « ptrace » de façon similaire à la commande « attach ».
Si nécessaire, la phase d'injection d'appels système 306 peut également être utilisée pour obtenir Ie contenu ou l'état de certaines ressources, en injectant les instructions de lecture correspondantes.
Ci-dessous figurent, à titre d'exemple en langage C pour un environnement POSIX, des instructions de programme utilisées dans un processus contrôleur PCl pour réaliser une prise de contrôle 301 d'un processus dont l'identifiant est « pid », c'est-à-dire dont la valeur est contenue dans la variable nommée « pid ».
Instruction de chargement de la fonction « ptrace » : #include <sys/ptrace.h>
Définition de la fonction « attach » qui réalise cette prise de contrôle : int attachant pid)
{ int status;
/* Prise de contrôle d'un processus par ptrace. Le processus * est défini par son process id 7 ptrace(PTRACE_ATTACH, pid, 0, 0);
/* lorsque le process est bloqué, SIGSTOP nous est renvoyé 7 waitpid(pid, &status, 0); if (WIFSTOPPED(status)) /* STOP est dans le masque des signaux 7 retum OK; return ERROR;
}
Ci-dessous figurent, à titre d'exemple en langage C pour un environnement POSIX, des instructions de programme réalisant une injection d'instructions destinée à capturer la position du pointeur d'écriture d'un descripteur de fichier ouvert par le processus capturé.
Déclaration d'une fonction nommée « ptrace_syscall », utilisée pour injecter n'importe quel appel système « syscall » associé à des arguments « argc », dans un processus dont l'identifiant est « pid » : int ptrace_syscall(pid_t pid, pid_t *tpid, int scratch, int syscall, int argc, ...);
Définition d'une macro utilisant la fonction « ptrace_sγscall », à utiliser pour réaliser l'injection de l'appel système « l_seek » dans le processus dont l'identifiant est « p » : #define PT_LSEEK(p, fd, off, w) \ ptrace_syscall(p, 0, 0, SYSJseek, 3, \ 0, 0, fd, \
0, 0, off, \
0, 0, w)
Définition d'une fonction, utilisée dans l'application de redistribution de fonctionnement, appelant la macro « PT_SEEK » pour capturer la position du pointeur d'écriture, en injectant l'appel système « Iseek », assorti du paramètre « SEEK_CUR », dans le processus dont l'identifiant est « pid » ; int get_file_pos(int pid, /* process id du programme attaché */ int fd) /* descripteur de fichier ouvert par pid */
{ int file_pos = PT_LSEEK(pid, fd, 0, SEEK_CUR); return file_pos;
}Les figures 5 et 6 illustrent un exemple d'un procédé d'introspection multi-processus, appliqué à l'analyse d'un descripteur de fichier. Lorsqu'un processus fils utilise descripteur de fichier hérité d'un processus père, les deux processus père et fils utilisent deux descripteurs différents, mais qui pointent tous les deux sur le même fichier ou container de données doté d'un unique pointeur de position. Il s'agit alors de deux instances différentes d'un même objet initial, appelées descripteurs « partagés », par opposition à des descripteurs « séparés ». Or, il peut être utile de sauvegarder la nature de tels descripteurs de fichiers dans le cadre d'une capture d'état, de façon à garder une même cohérence au sein des processus qui seront ultérieurement restaurés à partir de cette capture.
Le procédé d'introspection multi-processus est alors utilisé pour déterminer si deux descripteurs de fichiers FDA et FDB, utilisés par deux processus différents PA et PB et pointant sur des fichiers FA et FB, sont des descripteurs séparés ou partagés.
En une étape 501, un processus contrôleur PCl injecte une instruction d'appel système au sein du premier processus cible PA. Cet appel système réalise une lecture ptAO de la position du pointeur de lecture/écriture du descripteur de fichier FDA de ce premier processus cible PA.
Ce processus contrôleur PCl injecte des instructions d'appel système au sein du deuxième processus cible PB. En une étape 502, l'un de ces appels système réalise tout d'abord une lecture ptBO de la position du pointeur de lecture/écriture du descripteur de fichier FDB de ce deuxième processus cible PB.
En une étape 503, un autre de ces appels système, par exemple une instruction « Iseek » réalise ensuite une modification de la position de ce même pointeur.
En une étape 504, le processus contrôleur PCl injecte une instruction d'appel système au sein du premier processus cible PA. Cet appel système réalise une nouvelle lecture ptAl de la position du pointeur de lecture/écriture du descripteur de fichier FDA de ce premier processus cible
PA.
En une étape 505, le processus contrôleur PCl compare alors les valeurs ptAO et ptAl obtenues par les deux lectures de position du pointeur du premier descripteur FDl.
Si ces valeurs sont égales, alors cela signifie que ces deux descripteurs FDA, FDB utilisent le même pointeur, et sont donc des descripteurs partagés. En une étape 506, le processus contrôleur PCl mémorise alors une donnée représentant cette information.
En une étape 507, le processus contrôleur PCl injecte ensuite une instruction d'appel système au sein d'un des deux processus cibles, par exemple PB, pour ramener le pointeur à sa position initiale ptBO.
Si ces valeurs sont différentes, cela signifie que ces deux descripteurs FDA, FDB n'utilisent pas le même pointeur, et sont donc des descripteurs séparés. En une étape 507, le processus contrôleur PCl mémorise alors une donnée représentant cette information. En une étape 508, le processus contrôleur PCl injecte ensuite une instruction d'appel système au sein du deuxième processus cible PB pour ramener son pointeur à sa position initiale ptBO.
Dans les deux cas, le pointeur modifié est ramené à sa position initiale, et le procédé est donc bien transparent pour les deux processus cible.
La figure 4 illustre l'utilisation du procédé de gestion de fonctionnement selon l'invention pour réaliser une opération de mise à jour ou de restauration d'un processus, dit processus de reprise, et de son environnement d'exécution, par un processus contrôleur. Cette figure représente une opération de restauration, comprenant une partie 401, 402, 403 de création du processus de reprise.
Le processus contrôleur déclenche cette création en initialisant 401 un nouveau processus, dit processus de reprise, sous son contrôle (technique de « forking »), puis en utilisant une instruction « ptrace(TRACEMEM,...) » avant d'en lancer l'exécution.
Le processus de reprise démarre alors normalement en chargeant 402 les différentes ressources comme lors d'un démarrage à froid classique. A ce stade commence le procédé proprement dit de mise à jour de l'état d'un processus de reprise, c'est-à-dire le procédé qui peut être utilisé sur un processus de reprise existant déjà.
Si la mise à jour se fait dans la foulée d'un démarrage de processus de reprise, ce processus de reprise s'arrête 404 immédiatement après son chargement, du fait de son mode de lancement, et rappelle le processus contrôleur. Si la mise à jour se fait sur un processus de reprise préexistant, le processus contrôleur commence par prendre le contrôle 405 du processus capturé, par exemple par une instruction « attach » basée sur la routine « ptrace ». Le processus contrôleur réalise 406 alors une sélection et une lecture de données sauvegardées précédemment et constituant un état de point de reprise. A partir du contenu de cet de point de reprise, le processus contrôleur évalue les modifications de structure et de contenu à réaliser dans l'environnement d'exécution du processus de reprise tel qu'il se trouve pour l'amener à l'état de point de reprise sélectionné.
Si certaines des modifications de structure sont possibles directement depuis le processus contrôleur, celui-ci les réalise par lui-même 407.
Pour les modifications de structure qui ne lui sont pas accessibles, le processus contrôleur prépare une liste d'appels système qu'il injecte 408 dans le processus de reprise, selon le procédé de gestion de fonctionnement de l'invention.
Cette injection est utilisée par exemple pour modifier l'adressage et la cartographie des segments de mémoire utilisés, en injectant un ou plusieurs appels systèmes « mmap ». Le même principe est utilisé pour tout ou partie des ressources système qui doivent être recrées pour arriver à un état identique à l'état de point de reprise sélectionné. Ces ressources système sont par exemples des ressources de type « file », « socket », « pipe », « timer », « terminal control », etc.
Une fois que les structures de ressources sont adéquates, le processus contrôleur réalise 409 une écriture de ces ressources système en fonction des données de l'état de point de reprise, pour amener le processus de reprise à l'état où se trouvait le processus capturé lors de l'établissement du pont de reprise sélectionné.
Le processus contrôleur relance 410 alors l'exécution du processus de reprise et le libère 411 de son contrôle, par exemple par une commande « detach », basée sur la routine « ptrace » de façon similaire à la commande « attach ». Si nécessaire, la phase d'injection d'appels système 408 peut également être utilisée pour écrire le contenu ou l'état de certaines ressources, en injectant les instructions de lecture correspondantes.
Du fait qu'elle s'opère depuis un processus extérieur au processus de reprise, cette opération de restauration est bien plus simple et performante que si elle devait se faire par des opérations prévues à l'intérieur même de ce processus de reprise.
Ci-dessous figurent, à titre d'exemple en langage C pour un environnement POSIX, des instructions de programme réalisant une injection d'instructions destinée à restaurer la position du pointeur d'écriture d'un descripteur de fichier ouvert par ou pour le processus de reprise.
Ces instructions utilisent les mêmes fonction « ptrace_syscall » et macro « PT_SEEK » que celles décrites plus haut pour l'opération de capture. Définition d'une fonction, utilisée dans l'application de redistribution de fonctionnement, appellant la macro « PT_SEEK » pour restaurer la position du pointeur d'écriture, en injectant l'appel système « Iseek », assorti du paramètre « SEEK_SET », dans le processus dont l'identifiant est « pid » : int set_file_pos(int pid, int fd, int filepos) /* extrait du checkpoint ou point de reprise */
{ return PT_LSEEK(pid, fd, filepos, SEEK_SET); }
Dans le cas d'applications comprenant plusieurs processus, ou tâches, susceptibles de s'exécuter simultanément, l'établissement d'un de point de reprise peut nécessiter de capturer l'état de plusieurs de ces processus. Pour cela, l'utilisation d'un ou plusieurs processus contrôleurs extérieurs aux processus à capturer est un avantage qu'apporte le procédé selon l'invention.
Dans ce cas, l'application de redistribution de fonctionnement réalise une opération de capture selon l'invention sur plusieurs processus capturés, de façon à synchroniser ou à coordonner l'interruption initiale 301 de chacune des opérations de capture et la suspension des ressources concernées.
Lors d'une capture de plusieurs processus, certaines données en cours de transmission entre plusieurs processus peuvent se trouvées « figées » au sein du mécanisme logiciel interprocessus IPC gérant ces transmissions, par exemple l'objet logiciel « Inter Process Communication » dans un environnement de type Unix.
De façon à éviter de perturber la cohérence de l'état de point de reprise qui sera sauvegardé, l'application de redistribution de fonctionnement utilise le procédé de gestion de fonctionnement selon l'invention pour injecter dans chacun des processus interrompus les appels systèmes pour gérer ces données en cours de transmission. Il pourra s'agir par exemple de purger les files d'attente (pipe) de l'IPC des données non traitées dans le cadre d'une opération de capture d'état de processus lors d'un point de reprise (checkpoint), ou de restaurer ces mêmes données dans le cas d'une mise à jour de processus.
En effet, dans une situation de capture de l'état de plusieurs processus communiquant entre eux, lorsqu'un processus est suspendu pour capture, il peut y avoir des données en attente au sein de l'agent interprocessus IPC, à destination de ce processus suspendu. Une fois que tous les processus à capturer sont interrompus, pour chaque processus à capturer, l'opération de capture comprend alors en outre une analyse et une mémorisation de toutes les données de communications, ou paquets, qui lui ont destinées mais n'ont pas encore été reçues. Dans les systèmes où cet agent interprocessus est géré par le système, par exemple dans un module kernel pour le cas d'Unix, il est avantageux de ne pas avoir à intervenir dans le système. Le processus contrôleur PCl utilise alors le procédé de gestion de fonctionnement selon l'invention pour injecter dans le processus en cours de capture des appels système qui vont demander une lecture de ces données de communication en cours de transit. Le processus contrôleur récupère alors ces données et les sauvegarde au sein de l'état de point de reprise.
Dans une situation de restauration, lorsque tous les processus de reprise sont suspendus, le processus contrôleur PC2 utilise également le processus de gestion selon l'invention pour injecter dans chaque processus de reprise des appels systèmes qui vont écrire au sein de l'agent interprocessus IPC les paquets en transit qui avaient été mémorisés dans l'état de point de reprise. Par ailleurs, lorsqu'une application comprend plusieurs processus, certains de ces processus peuvent avoir entre eux des relations d'héritage. C'est-à-dire qu'un processus « fils » peut avoir été créé à partir d'un processus « père », et hériter par cette relation d'héritage de certaines caractéristiques ou ressources de son environnement d'exploitation, en particulier de type « file descriptor ».
Lors de la capture des processus d'une application, le processus contrôleur PCl va utiliser le processus de gestion selon l'invention pour injecter dans chaque processus capturé des appels système qui vont analyser ses éventuelles relations d'héritage avec un ou plusieurs autres processus. Les résultats de ces analyses seront alors sauvegardées au sein de l'état de point de reprise en cours de constitution.
Lors de la restauration de ces mêmes processus, le processus contrôleur PCl va utiliser le processus de gestion selon l'invention pour injecter dans chaque processus de reprise des appels système qui vont recréer ces mêmes relations d'héritage qui avaient été mémorisés dans l'état de point de reprise.
Bien sûr, l'invention n'est pas limitée aux exemples qui viennent d'être décrits et de nombreux aménagements peuvent être apportés à ces exemples sans sortir du cadre de l'invention.

Claims

REVENDTCATIONS
1. Procédé pour gérer le fonctionnement d'une application logicielle comprenant au moins un premier processus logiciel, dit processus cible, s'exécutant sur au moins un ordinateur et dans un environnement d'exécution comprenant au moins un espace mémoire d'exécution, caractérisé en ce qu'il comprend une opération d'injection temporaire d'au moins une instruction exécutable dans l'espace mémoire d'exécution du processus cible, par au moins un deuxième processus logiciel, dit processus contrôleur, extérieur à l'application et apte à agir sur le déroulement du processus cible, cette instruction exécutable réalisant une analyse ou une modification de l'environnement d'exécution de ce processus cible.
2. Procédé selon la revendication 1, caractérisé en ce que l'opération d'injection comprend des étapes de :
- interruption de l'exécution du processus cible (202) par le processus contrôleur ;
- écriture (207) par le processus contrôleur dans une partie, dite zone réattribuée, de l'espace mémoire d'exécution du processus cible, d'instructions injectées réalisant le mécanisme d'analyse ou de modification ;
- exécution (211), par le processus cible, de ces instructions injectées ;
- restauration (214) par le processus contrôleur, par écriture dans la zone réattribuée, des instructions du processus cible qui y étaient mémorisées avant l'interruption (202) ;
- exécution (215) de la suite des instructions du processus cible.
3. Procédé selon l'une des revendications 1 ou 2, caractérisé en ce qu'il réalise une opération d'introspection d'au moins deux processus introspectés, chacun de ces processus introspectés (PA, PB) utilisant une première ressource (FDA, respectivement FDB) comportant elle-même un pointeur (IdPtA, respectivement IdPtB) désignant une deuxième ressource (FA, FB) comportant elle-même un attribut (ptA, ptB) qui est accessible audit processus à travers ledit pointeur , le procédé comprenant les étapes suivantes :
- injection (501, 502) par le processus contrôleur (PCl) dans chacun des deux processus introspectés (PA, PB) d'au moins une instruction système réalisant une lecture initiale de la valeur (ptAO, respectivement ptBO) de l'attribut (ptA, ptB) de la deuxième ressource (FA, FB) correspondant à chacun desdits processus introspectés ;
- injection (503) par le processus contrôleur (PCl) dans l'un des deux processus introspectés, dit processus de test (PB), d'au moins une instruction système réalisant une modification de la valeur (ptBO) de l'attribut (ptB) de la deuxième ressource (FB) correspondant audit processus test (PB) ;
- injection (504) par le processus contrôleur (PCl) dans l'autre processus introspecté, dit processus témoin (PA), d'au moins une instruction système réalisant une deuxième lecture de la valeur (ptAl) de l'attribut (ptA) de la deuxième ressource (FA) correspondant audit processus témoin (PA) ;
- comparaison (505) par le processus contrôleur (PCl) de la valeur de deuxième lecture (ptAl) avec la valeur de lecture initiale (ptAO) dudit processus témoin (PA) ;
- mémorisation (506, 508) par le processus contrôleur (PCl) d'une donnée représentant le résultat de ladite comparaison et injection (507, 509)) par le processus contrôleur (PCl) dans le processus de test (PB), d'au moins une instruction système réalisant une modification de la valeur (ptBO) de l'attribut (ptB) de la deuxième ressource (FB) correspondant audit processus test (PB), de façon à lui redonner sa valeur (ptBO) de lecture initiale.
4. Procédé selon l'une des revendications 1 à 3, caractérisé en ce qu'il réalise une opération de capture de l'état du processus cible, dit processus capturé (PCA), comprenant des étapes de :
- prise de contrôle (301) du processus capturé par un processus contrôleur ; - injection (306) par le processus contrôleur (PCl) dans le processus capturé d'au moins une instruction d'appel système réalisant une analyse (307) de la structure de l'environnement d'exécution du processus capturé ; - mémorisation (310) ou transmission de données de résultat (311) représentant le résultat de cette analyse et restauration de l'espace mémoire du processus capturé ;
- exécution (312) de la suite des instructions du processus capturé.
5. Procédé selon la revendication 4, caractérisé en ce qu'il réalise une opération de capture de l'état d'au moins deux processus (PCA, PCB) de cette application, l'interruption de ces deux processus se faisant soit de façon simultanée soit en des points de leurs déroulements respectifs dont l'un est calculé en fonction de l'autre.
6. Procédé selon l'une des revendications 4 ou 5, caractérisé en ce que le processus capturé (PCA) échange des données de communication avec au moins un autre processus (PCB) par l'intermédiaire d'au moins un agent logiciel interprocessus (IPC) extérieur à l'application, l'opération de capture comprenant en outre des étapes de :
- injection, par le processus contrôleur dans le processus capturé d'au moins une instruction d'appel système réalisant la lecture dans l'agent interprocessus d'au moins une donnée de communication en provenance d'un autre processus de l'application et non encore reçue par le processus capturé ;
- mémorisation ou transmission de cette donnée de communication en tant que donnée de résultat.
7. Procédé selon l'une des revendications 4 à 6, caractérisé en ce que l'environnement d'exécution du processus capturé (PCA) supporte la transmission de caractéristiques entre processus par des relations d'héritage, l'opération de capture comprenant en outre des étapes de :
- injection, par le processus contrôleur dans le processus capturé d'au moins une instruction d'appel système réalisant une analyse des relations d'héritage du processus capturé avec au moins un autre processus de l'application ;
- mémorisation ou transmission de données de résultat représentant les relations d'héritage du processus capturé.
8. Procédé selon l'une des revendications 1 ou 2, caractérisé en ce qu'il réalise une opération de restauration, par un processus contrôleur (PC2) à partir de données dites de reprise, de l'état d'au moins un processus d'application logicielle, dit processus de reprise (PCA'), l'opération de restauration comprenant des étapes de :
- interruption (404, 405) de l'exécution du processus de reprise par le processus contrôleur (PC2) ;
- injection (408) par le processus contrôleur dans le processus de reprise d'au moins une instruction d'appel système créant ou modifiant la structure d'au moins un objet logiciel appartenant à l'environnement d'exécution du processus de reprise, en fonction des données de reprises ;
- écriture (409), à partir des données de reprise, de l'espace mémoire d'exécution du processus de reprise ; - lancement (410) du processus de reprise et exécution (411) de la suite de ses instructions.
9. Procédé selon la revendication 8, caractérisé en ce que l'environnement d'exécution du processus de reprise supporte l'échange de données de communication entre plusieurs processus (PCA', PCB'), par l'intermédiaire d'au moins un agent logiciel interprocessus (IPC) extérieur à l'application, l'opération de restauration comprenant en outre une étape de :
- injection, par le processus contrôleur dans le processus capturé d'au moins une instruction d'appel système réalisant, à partir des données de reprise, l'écriture au sein de l'agent interprocessus (IPC) d'au moins une donnée représentant une donnée de communication à destination du processus de reprise.
10. Procédé selon l'une des revendications 8 ou 9, caractérisé en ce que l'environnement d'exécution du processus de reprise (PCA') supporte la transmission de caractéristiques entre processus par des relations d'héritage, l'opération de restauration comprenant en outre une étape de : - injection, par le processus contrôleur dans le processus de reprise d'au moins une instruction d'appel système créant ou modifiant, à partir des données de reprise, au moins une relations d'héritage du processus de reprise avec au moins un autre processus de l'application.
11. Procédé selon l'une des revendications précédentes, caractérisé en ce qu'il réalise une réplication d'au moins un processus de l'application, dit processus original, en un processus clone, et comprend les étapes suivantes : - capture de l'état du processus original par un procédé selon l'une des revendications 2 à 6 ;
- utilisation de données de résultat, issues de la capture, pour mémoriser un objet logiciel appelé point de reprise, représentant un état de ce processus original en un point de son exécution ; - utilisation de données du point de reprise pour restaurer au moins un processus clone dans un état reproduisant l'état du processus original.
12. Procédé selon la revendication 11, caractérisé en ce qu'il réalise une redistribution de tout ou partie d'une application logicielle dite redistribuée, exécutée dans une architecture multi-ordinateurs (cluster) et comprenant au moins un processus, dit processus initial, fournissant un traitement de données en étant exécuté à un instant donné sur au moins un ordinateur du cluster, appelé nœud primaire ou opérationnel (OP), d'autres ordinateurs dudit cluster étant appelés nœuds secondaires, cette opération de redistribution comprenant les étapes suivantes : réplication d'au moins un processus initial en au moins un processus secondaire exécuté sur un nœud secondaire ;
- basculement de tout ou partie du traitement de données du processus initial vers au moins un processus secondaire.
13. Procédé selon la revendication 12, caractérisé en ce qu'il comprend en outre les étapes suivantes :
- réplication de tous les processus exécutés par le nœud opérationnel en un ou plusieurs processus secondaires exécutés sur au moins un nœud secondaire ;
- basculement de la totalité des traitements de données desdits processus vers au moins un desdits processus secondaires.
14. Procédé selon l'une des revendications 1 à 10, caractérisé en ce qu'il réalise une suspension d'une application logicielle comprenant au moins un processus exécuté sur au moins un ordinateur, cette opération de suspension comprenant les étapes suivantes :
- capture de l'état de l'ensemble des processus de l'application ; - utilisation de données de résultat, issues de la capture, pour mémoriser un objet logiciel appelé point de reprise, représentant un état de cette application en un point de son exécution ;
- utilisation de données du point de reprise pour restaurer un ou plusieurs processus clones dans un état reproduisant l'état de l'ensemble des processus capturés.
15. Procédé selon l'une des revendications 1 à 10, caractérisé en ce qu'il réalise une fiabilisation du fonctionnement d'une application logicielle, dite application fiabilisée, exécutée dans une architecture multi-ordinateurs (cluster) et fournissant un service déterminé, au moins un processus (PCA) de cette application étant exécuté à un instant donné sur au moins un ordinateur du cluster, appelé nœud primaire ou opérationnel (OP), d'autres ordinateurs dudit cluster étant appelés nœuds secondaires (SB), cette fiabilisation comprenant les étapes suivantes : - capture par au moins un processus contrôleur (PCl) de l'état de l'ensemble des processus de cette application fiabilisée ;
- utilisation de données de résultat, issues de la capture, pour mémoriser un objet logiciel appelé point de reprise, représentant un état de cette application fiabilisée en un point de son exécution ; - détection au sein du nœud opérationnel d'une défaillance matérielle ou logicielle affectant le fonctionnement de l'application fiabilisée ;
- utilisation de tout ou partie des données du point de reprise pour restaurer, sur au moins un nœud secondaire, un ou plusieurs processus d'une application de secours en un état reproduisant l'état de l'ensemble des processus de l'application fiabilisée ;
- basculement de tout ou partie du service vers l'application de secours d'au moins l'un desdits noeuds secondaires.
16. Procédé selon la revendication 11, caractérisé en ce qu'il réalise une réplication holistique de l'état d'une application dite originale en une application clone, en utilisant ledit procédé de réplication pour répliquer l'ensemble des processus et ressources de l'application originale en tant que processus et ressources de l'application clone.
17. Procédé selon la revendication 16, caractérisé en ce qu'il réalise une fiabilisation d'une application logicielle dite fiabilisée, exécutée dans une architecture multhordinateurs (cluster) et fournissant ur service déterminé, au moins un processus de cette application, dit processus fiabilisé (PCA), étant exécuté à un instant donné sur au moins un ordinateur du cluster, appelé nœud primaire ou opérationnel (OP), d'autres ordinateurs dudit cluster étant appelés nœuds secondaires, cette fiabilisation comprenant les étapes suivantes : mise en œuvre d'un procédé de réplication holistique pour répliquer, sur au moins un nœud secondaire (SB), une application de secours dans un état identique à celui de l'application fiabilisée ;
- détection au sein du nœud opérationnel d'une défaillance matérielle ou logicielle affectant le fonctionnement de l'application fiabilisée ;
- basculement de tout ou partie du service vers ladite application de secours d'au moins un des nœuds secondaires.
18. Système multi-ordinateurs comprenant une gestion de processus applicatifs mettant en œuvre le procédé selon l'une des revendications 1 à 16.
EP05778898A 2004-06-30 2005-06-22 Procede de gestion d'un processus logiciel, procede et systeme de redistribution ou de continuite de fonctionnement dans une architecture multi-ordinateurs Withdrawn EP1782201A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0407180A FR2872605B1 (fr) 2004-06-30 2004-06-30 Procede de gestion d'un processus logiciel, procede et systeme de redistribution ou de continuite de fonctionnement dans une architecture multi-ordinateurs
PCT/FR2005/001564 WO2006010812A2 (fr) 2004-06-30 2005-06-22 Procede de gestion d'un processus logiciel, procede et systeme de redistribution ou de continuite de fonctionnement dans une architecture multi-ordinateurs

Publications (1)

Publication Number Publication Date
EP1782201A2 true EP1782201A2 (fr) 2007-05-09

Family

ID=34948448

Family Applications (1)

Application Number Title Priority Date Filing Date
EP05778898A Withdrawn EP1782201A2 (fr) 2004-06-30 2005-06-22 Procede de gestion d'un processus logiciel, procede et systeme de redistribution ou de continuite de fonctionnement dans une architecture multi-ordinateurs

Country Status (5)

Country Link
US (1) US20080307265A1 (fr)
EP (1) EP1782201A2 (fr)
CN (1) CN100530120C (fr)
FR (1) FR2872605B1 (fr)
WO (1) WO2006010812A2 (fr)

Families Citing this family (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7685172B2 (en) 2007-04-27 2010-03-23 International Business Machines Corporation In-flight file descriptors checkpoint
US7797576B2 (en) 2007-04-27 2010-09-14 International Business Machines Corporation Checkpoint of applications using UNIX® domain sockets
US7950019B2 (en) 2007-05-21 2011-05-24 International Business Machines Corporation Method and apparatus for checkpoint and restarting a stream in a software partition
US8527650B2 (en) 2007-05-21 2013-09-03 International Business Machines Corporation Creating a checkpoint for modules on a communications stream
US7930327B2 (en) 2007-05-21 2011-04-19 International Business Machines Corporation Method and apparatus for obtaining the absolute path name of an open file system object from its file descriptor
US9384159B2 (en) 2007-05-24 2016-07-05 International Business Machines Corporation Creating a checkpoint for a software partition in an asynchronous input/output environment
US8127289B2 (en) 2007-06-27 2012-02-28 International Business Machines Corporation Enabling a third party application to participate in migration of a virtualized application instance
US7792983B2 (en) 2007-07-31 2010-09-07 International Business Machines Corporation Method and apparatus for checkpoint and restart of pseudo terminals
US8006254B2 (en) 2007-10-04 2011-08-23 International Business Machines Corporation Bequeathing privilege to a dynamically loaded module
US8156510B2 (en) 2007-10-04 2012-04-10 International Business Machines Corporation Process retext for dynamically loaded modules
US8495573B2 (en) 2007-10-04 2013-07-23 International Business Machines Corporation Checkpoint and restartable applications and system services
US7933991B2 (en) 2007-10-25 2011-04-26 International Business Machines Corporation Preservation of file locks during checkpoint and restart of a mobile software partition
US7933976B2 (en) 2007-10-25 2011-04-26 International Business Machines Corporation Checkpoint and restart of NFS version 2/version 3 clients with network state preservation inside a workload partition (WPAR)
US9473598B2 (en) 2007-12-18 2016-10-18 International Business Machines Corporation Network connection failover during application service interruption
US9928349B2 (en) * 2008-02-14 2018-03-27 International Business Machines Corporation System and method for controlling the disposition of computer-based objects
US8572237B2 (en) * 2008-12-16 2013-10-29 Sap Ag Failover mechanism for distributed process execution
US7945808B2 (en) * 2009-01-30 2011-05-17 International Business Machines Corporation Fanout connectivity structure for use in facilitating processing within a parallel computing environment
US20110191627A1 (en) * 2010-01-29 2011-08-04 Maarten Koning System And Method for Handling a Failover Event
JP5678311B2 (ja) * 2011-03-15 2015-03-04 ヒョンダイ モーター カンパニー 通信テスト装置及び方法
CN102117224B (zh) * 2011-03-15 2013-01-30 北京航空航天大学 一种面向多核处理器的操作系统噪声控制方法
CN102984184B (zh) * 2011-09-05 2017-09-19 上海可鲁系统软件有限公司 一种分布式系统的服务负载均衡方法及装置
US8782651B2 (en) 2011-09-26 2014-07-15 International Business Machines Corporation Dynamically redirecting a file descriptor of an executing process by another process by optionally suspending the executing process
CN102495802B (zh) * 2011-12-26 2015-03-18 华为技术有限公司 测试软件系统的方法和装置以及计算机系统
CN104077184B (zh) * 2013-03-25 2018-12-11 腾讯科技（深圳）有限公司 一种应用程序的进程控制方法及计算机系统
US9304896B2 (en) * 2013-08-05 2016-04-05 Iii Holdings 2, Llc Remote memory ring buffers in a cluster of data processing nodes
CN103885364B (zh) * 2014-03-24 2016-09-28 三和智控(北京)系统集成有限公司 一种通过计划队列实现控制逻辑的动态延时调用的方法
CN111435316A (zh) * 2019-01-14 2020-07-21 阿里巴巴集团控股有限公司 一种资源扩容方法及其装置

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5297274A (en) * 1991-04-15 1994-03-22 International Business Machines Corporation Performance analysis of program in multithread OS by creating concurrently running thread generating breakpoint interrupts to active tracing monitor
CA2106280C (fr) * 1992-09-30 2000-01-18 Yennun Huang Appareil et methodes de traitement insensible aux defaillances faisant appel a un processus de surveillance par demon et une bibliotheque insensible aux defaillances en vue d'offrir differents degres d'insensibilite aux defaillances
US7047521B2 (en) * 2001-06-07 2006-05-16 Lynoxworks, Inc. Dynamic instrumentation event trace system and methods
US6898785B2 (en) * 2001-08-16 2005-05-24 Hewlett-Packard Development Company, L.P. Handling calls from relocated instrumented functions to functions that expect a return pointer value in an original address space
FR2843209B1 (fr) * 2002-08-02 2006-01-06 Cimai Technology Procede de replication d'une application logicielle dans une architecture multi-ordinateurs, procede pour realiser une continuite de fonctionnement mettant en oeuvre ce procede de replication, et systeme multi-ordinateurs ainsi equipe.

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2006010812A2 *

Also Published As

Publication number Publication date
CN100530120C (zh) 2009-08-19
CN101002177A (zh) 2007-07-18
WO2006010812A3 (fr) 2007-03-22
FR2872605B1 (fr) 2006-10-06
US20080307265A1 (en) 2008-12-11
WO2006010812A2 (fr) 2006-02-02
FR2872605A1 (fr) 2006-01-06

Similar Documents

Publication Publication Date Title
WO2006010812A2 (fr) Procede de gestion d&#39;un processus logiciel, procede et systeme de redistribution ou de continuite de fonctionnement dans une architecture multi-ordinateurs
EP4004738B1 (fr) Débogage à déplacement temporel avec remplacement de code à chaud
CA2493407C (fr) Procede de replication d&#39;une application logicielle dans une architecture multi-ordinateurs, procede pour realiser une continuite de fonctionnement mettant en oeuvre ce procede de replication, et systeme multi-ordinateurs ainsi equipe
CN107710215A (zh) 在测试设施中的移动计算装置安全的方法和设备
CN106155778A (zh) 一种应用容器的启动方法及系统
FR2881241A1 (fr) Procede d&#39;optimisation de la journalisation et du rejeu d&#39;application multi-taches dans un systeme informatique mono-processeur ou multi-processeurs
US7877749B2 (en) Utilizing and maintaining data definitions during process thread traversals
US7823153B1 (en) System and method for detecting and logging in-line synchronization primitives in application program code
US11151020B1 (en) Method and system for managing deployment of software application components in a continuous development pipeline
US10461991B1 (en) Dynamic replication peering
De Iasio et al. A framework for microservices synchronization
Jung et al. Oneos: Middleware for running edge computing applications as distributed posix pipelines
Stenbom Refunction: Eliminating serverless cold starts through container reuse
Bouizem Fault tolerance in FaaS environments
US20120102505A1 (en) Dynamic process virtualization
US6910103B2 (en) Caching data
CN118467256B (zh) 一种集群的业务故障恢复方法、装置、介质以及产品
FR2883083A1 (fr) Procede d&#39;execution d&#39;une application dans un conteneur virtuel formant une session d&#39;environnement virtualise
Fördős et al. CRDTs for the configuration of distributed Erlang systems
Alexandre R-Check: A Reactive Checkpointing Approach for Serverless Computing
US11880294B2 (en) Real-time cross appliance operational intelligence during management appliance upgrade
Mustafa Kubernetes
Buitrago Suárez PARSEC: an adaptive and efficient platform for reducing cold start in serverless computing
Zhang Towards Elastic and Cost-effective Stateful Serverless Systems
Naser et al. Docker Containers and Images for Robot Operating System (ROS)-Based Applications

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20070124

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU MC NL PL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL BA HR LV MK YU

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20071126

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20130103