WO2016156736A1 - Procede d'aide a l'identification d'incidents dans une architecture d'informatique dans le nuage - Google Patents

Procede d'aide a l'identification d'incidents dans une architecture d'informatique dans le nuage Download PDF

Info

Publication number
WO2016156736A1
WO2016156736A1 PCT/FR2016/050712 FR2016050712W WO2016156736A1 WO 2016156736 A1 WO2016156736 A1 WO 2016156736A1 FR 2016050712 W FR2016050712 W FR 2016050712W WO 2016156736 A1 WO2016156736 A1 WO 2016156736A1
Authority
WO
WIPO (PCT)
Prior art keywords
virtual machine
operating system
machine
stream
hypervisor
Prior art date
Application number
PCT/FR2016/050712
Other languages
English (en)
Inventor
Aurélien WAILLY
Aymeric TABOURIN
Original Assignee
Orange
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 Orange filed Critical Orange
Publication of WO2016156736A1 publication Critical patent/WO2016156736A1/fr

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/1497—Details of time redundant execution on a single processing unit
    • 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
    • G06F11/1484—Generic software techniques for error detection or fault masking by means of middleware or OS functionality involving virtual machines
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/362—Software debugging
    • G06F11/3636—Software debugging by tracing the execution of the program
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0631—Management of faults, events, alarms or notifications using root cause analysis; using analysis of correlation between notifications, alarms or events based on decision criteria, e.g. hierarchy, tree or time analysis
    • H04L41/0645—Management of faults, events, alarms or notifications using root cause analysis; using analysis of correlation between notifications, alarms or events based on decision criteria, e.g. hierarchy, tree or time analysis by additionally acting on or stimulating the network after receiving notifications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/40—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks using virtualisation of network functions or resources, e.g. SDN or NFV entities
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45591—Monitoring or debugging support

Definitions

  • the present invention relates to a method for assisting the identification of incidents on a virtual machine included in a virtualized computer environment, that is to say virtualized.
  • a cloud computing architecture typically includes at least one host server that has hardware resources on which a cloud computing service provided by a service provider to one or more clients is based.
  • the service provider provides the client with one or more virtual machines that constitute the client-specific service execution environment.
  • the virtual machine uses the resources of the host server to run.
  • An incident is an event that is not part of the expected and standard operation of the virtual machine and may cause an interruption of its execution, a decrease in the quality of service rendered by the virtual machine, and so on.
  • the service rendered by the virtual machine is therefore interrupted, which can pose a problem in terms of the availability of the service when no redundancy method has been put in place.
  • One of the aims of the invention is to remedy the shortcomings / disadvantages of the state of the art and / or to make improvements thereto.
  • the invention proposes a method of assisting the identification of incidents on a virtual machine hosted by a host system, the virtual machine comprising an operating system communicating with a hypervisor of the host system, said hypervisor interfaced between the operating system and hardware resources of the host system, said method comprising the following steps, implemented by the hypervisor:
  • the data stream is duplicated into a second stream, said second stream being transmitted to the operating system of a second virtual machine with an offset from the transmission of the stream to the operating system of the virtual machine , the second virtual machine being distinct from the virtual machine, an incident occurring on the virtual machine occurring on the second machine only at least with the offset.
  • the method described here thus makes it possible to have a second virtual machine which is exactly in the same state as the virtual machine but with a lag in the past. This makes it possible to observe precisely what happens between the actual occurrence of an incident on the virtual machine and the occurrence of this same incident on the second virtual machine, which occurs only after the shift.
  • the virtual machines are distinct: although they have the same characteristics, they are installed on separate memory pages. There is therefore no load sharing between the virtual machines, nor any redundancy. The virtual machine does not undergo any edge effects because of the duplication of the flow and the processing performed on the second virtual machine.
  • a provider of virtualization solutions can propose a new security and investigation offer that does not currently exist. Analyzing compromised systems in virtual environments is costly and time consuming. Such an offer is undeniably a plus.
  • the method further comprises the steps of:
  • the offset is expressed by a time interval. Expressing the offset by a duration constitutes a first variant embodiment. In an exemplary embodiment of this variant, the time interval is less than or equal to 20 seconds.
  • the offset is expressed by a number of data streams, a data stream comprising the result of the execution of an interrupt by the operating system of the virtual machine. Expressing the offset in terms of the number of instructions constitutes a second variant embodiment.
  • the number of data streams is less than or equal to 10000.
  • This value is representative of a delay of twenty seconds as previously planned. Expressing the offset in the form of a number of data streams each corresponding to the result of the execution of an interrupt can facilitate the scheduling of the observation of the execution step by step of the second virtual machine by choosing steps of execution function of a number of instructions. Such a value may be easier to quantify when defining an incident identification process.
  • an observation step comprises at least two data streams.
  • An observation step that includes several data streams allows the operator to group the processing of several data streams that are not problematic.
  • the invention also relates to a server implementing an entity for assisting in the identification of incidents occurring on a virtual machine hosted by the server, said entity residing in a virtual layer of the server, said virtual machine comprising a virtual system. operating communicating with a hypervisor of the server, said hypervisor interfacing between the operating system and hardware resources of the server, said server comprising:
  • reception means arranged to receive from the operating system, at least one machine instruction corresponding to an interruption at the level of the operating system, said interruption being consecutive to an event occurring at the virtual machine,
  • execution means arranged to execute the instruction by means of the hardware resources of the host system
  • duplication and transmission means arranged to duplicate the data stream in a second stream, and to transmit to the operating system a data stream comprising the result of the execution of the interrupt
  • the invention also relates to a computer program on a data medium and loadable in the memory of a computer, the program comprising code instructions for the execution of the steps of the method of assisting the identification of incidents. on a virtual machine as described above, when the program is run on said computer
  • the invention also relates to a data carrier in which the program described above is recorded.
  • FIG. 1 is a schematic representation of a cloud computing architecture model adapted for implementing the method of assisting the identification of an incident on a virtual machine, according to an exemplary embodiment of the invention. invention
  • FIG. 2 presents the steps of the method of assisting the identification of an incident on a virtual machine, according to a first embodiment of the invention
  • FIG. 3 is a schematic representation of a server hosting an incident identification assistance entity on a virtual machine, according to an exemplary embodiment of the invention.
  • An architecture model suitable for implementing a method of assisting the identification of incidents on a virtual machine comprised in a virtualized computing environment, according to an exemplary embodiment will now be described in connection with FIG. 1.
  • a cloud computing architecture (commonly referred to as “cloud computing") conforms to a model that includes multiple execution layers. Different models exist.
  • An exemplary cloud computing architecture model for an architecture that includes a host server 10 is described in connection with FIG.
  • the host server 10 thus comprises a first execution layer, or hardware execution layer 10-1.
  • This hardware execution layer 10-1 comprises a set of hardware resources r1, r2, r3, r4, etc., of the host server 10.
  • a hardware resource corresponds, for example, to memory, to a network interface, to a microphone -processor, etc.
  • a second execution layer is a 10-2 virtualization layer.
  • the virtualization layer 10-2 is adapted to present to one or more operating systems of virtual machines, for example the operating system OS1 of a virtual machine VM1, a virtual layer 10-3, a virtual resource space, constructed from a physical resource space of the host server 10, in this case the resource space r1, r2, r3, r4, etc. the hardware execution layer 10-1.
  • the virtualization layer 10-2 is implemented by a virtualization module usually called hypervisor 101 which manages the allocation of hardware resources between the different instances of virtual machines and provides virtual machines these virtualized resources.
  • the virtualization layer 10-2 is also suitable for creating, instantiating, releasing, placing virtual machines running concurrently on the same physical machine, here the host server 10.
  • a third execution layer is the virtual layer 10-3.
  • the resources associated with this layer are the virtual machines, for example the virtual machine VMl, which execute in the virtual environment made available by the host server 10 as a physical machine.
  • the virtual machines are, for example, client virtual machines that may comprise sensitive data or code to be protected.
  • an action at the virtual machine is handled conventionally by the operating system of the virtual machine as an interrupt.
  • An action is for example the movement of the mouse by a user, saving a file.
  • An interruption consists in interrupting the normal execution of a program by the microprocessor so as to execute another program, or interrupt routine, for example that intended to take into account the action of the user on the virtual machine.
  • the interrupt routine includes machine instructions, i.e. low-level instructions, in machine language, such as in assembler. These low-level instructions involve resources, such as memory, interfaces, devices, and so on.
  • the hypervisor 101 which makes virtualized resources available to the virtual machine is an intermediary between the operating system of the virtual machine and the hardware resources of the hardware execution layer 10-1 of the host system 10.
  • the hypervisor 101 when of an interruption in the operating system OS1 of the virtual machine VM1, the hypervisor 101 receives the OS1 OS machine instructions that imply the virtualized resources and controls the execution of these instructions from the hardware resources of the host system 10. It then transmits to the operating system OS1 the result of this execution in the form of a data stream comprising the result of this execution.
  • This stream thus includes events for virtual input / output devices used by the virtual machine VMl.
  • the processing of the interruption thus causes the actual movement of the mouse on a screen associated with the virtual machine VMl. It is known that the execution of the routine interrupt can not be interrupted, it is said that the instructions of the routine are executed atomically.
  • the hypervisor 101 manages the access of the OS1 operating system of the virtual machine VM1 to the underlying hardware architecture.
  • the virtualization layer 10-2, more precisely the hypervisor 101 comprises an incident identification assistance module 102, called an agent, adapted to enable a human operator to identify the origin of an incident on a virtual machine, for example the virtual machine VM1 when the agent 102 is associated with the virtual machine VM1 by the hypervisor 101.
  • An incident is an event that is not part of the standard operation and expected of a service, an application, or more generally of a virtual machine, and which causes, at the level of execution of the virtual machine, an interruption of its execution, or a decrease in the quality of service.
  • the incident identification assistance agent 102 is a stand-alone software module comprising code instructions for implementing some of the steps of the incident identification assistance method.
  • the incident detection assistance module 102 is arranged to help an operator identify the origin of an incident on the VM1 virtual machine.
  • the hypervisor 101 is arranged to duplicate the virtual machine VM1 into a second virtual machine VM1 '(in dashed lines in FIG. 1).
  • the second machine VMl ' has the same characteristics as the machine VM1: same network address, same MAC address, etc.
  • the hypervisor 101 is also arranged to allocate to the incident identification assistance agent 102 a buffer memory area (referred to as a "buffer" in English) on a memory page separate from the memory pages allocated to the virtual machines.
  • the incident identification assistance agent 102 is arranged to duplicate a stream of data received from the hypervisor, to send it on the one hand to the machine VM1 and to store it temporarily, before transmitting it. to the second virtual machine VMl '.
  • the agent 102 therefore delays the data flows to the second machine VMl '.
  • the agent 102 is also arranged to pause the execution of the second virtual machine, on command of an operator or on detection of an incident on the virtual machine VMl.
  • Agent 102 is also arranged to interact with the operator and to transmit step by step the streams stored in the second machine VM1 '.
  • the operator can execute, step by step, that is to say interruption by interruption, the data flows corresponding to the results of the interruptions and identify the origin of the incident, by consulting newspapers which he has and in observing the impacts of processing an interrupt on the second virtual machine.
  • SaaS Software-as-a-Service
  • PaaS Platinum-as-a-Service
  • IaaS International-as-a-Service
  • the Cloud Computing architecture is assumed to conform to the model described in relation to Figure 1.
  • a client has configured a VM1 virtual machine by specifying with a service provider the resources he wanted to have on the server 10 of the service provider in terms, for example memory size, type of service. memory card, number of processors and NICs, virtual machine version, etc.
  • the configuration is then used by the service provider to enable the hypervisor 101 to start the VM1 virtual machine made available to the client by allocating the resources defined by configuration.
  • a memory image of the virtual machine VM1 is stored in a database data (not shown). Changes made by the client to the VM1 virtual machine when executing this one in the runtime environment are thus taken into account during a subsequent restart.
  • the virtual machine VM1 is started or restarted by the service provider.
  • This start means that the virtual machine VM1 as stored or configured is loaded by the hypervisor 101 on the host server 10. All the resources configured for the machine VM1 are then provided by the hypervisor 101 to the virtual machine VM1 so that the it runs. The client can then have his virtual machine VMl to install all the software he needs for his activity.
  • the hypervisor 101 duplicates the virtual machine VM1 of the client.
  • This duplication consists in creating a second virtual machine VMl 'similar to the virtual machine VM1 of the client but nevertheless distinct.
  • Similar means that the VMl 'duplicated machine has the same characteristics as the virtual machine VM1 of the client: same network address, same MAC address; it has the same amount of resources, etc. However, it is installed on memory pages different from those used by the virtual machine VMl.
  • the duplicated machine VM1 ' is therefore distinct from the virtual machine VM1 but behaves similarly to the virtual machine VM1 as soon as it receives the same data streams.
  • the hypervisor 101 allocates to the incident identification assistance agent 102 a buffer memory area on a memory page different from those allocated to the virtual machine VM1 and the duplicated machine VM1 '.
  • the independence of this memory zone from the memory zones of the virtual machines guarantees the independence of the agent 102 for helping to identify problems with the operation of the virtual machines VM1 and VM1 '.
  • the second virtual machine VMl ' is started at the same time as the machine VMl, during the step E0 of starting or restarting, from the configuration of the virtual machine VMl.
  • the buffer memory area is allocated by the hypervisor 101 to the agent 102 during the start or restart step E0, independently of the start or restart of the virtual machine VM1.
  • the hypervisor 101 receives from the operating system OS1 of the virtual machine VM1 a sequence of at least one corresponding machine instruction to an interrupt routine. Specifically, an event at the virtual machine VM1 of the client triggers an interruption in the operating system OS1 VM1 virtual machine. This interruption corresponds to the sequence of instructions.
  • the event that causes an interruption is for example the movement of the mouse by the client, a request for file backup, etc.
  • an interrupt execution step E4 the OS1 operating system of the VM1 virtual machine controls the execution of the instruction sequence.
  • the instructions of the sequence are executed on the virtualized resources controlled by the hypervisor 101 which makes use of the underlying hardware resources. It is thus the hypervisor 101, which makes the virtualized resources available to the virtual machine VM1, which controls the execution of the sequence of instructions by means of the hardware resources of the host system 10.
  • the result of the execution of this instruction sequence constitutes a flow of data transmitted to the incident identification assistance agent 102 and intended to be transmitted to the virtual machine VM1.
  • the incident identification assistance agent 102 duplicates the stream received from the hypervisor 101 and intended for the VM1 virtual machine, and obtains a second stream called duplicate stream. It then transmits the stream in a conventional manner to the virtual machine VM1 as a result of the processing of the interrupt and stores the duplicated stream in the buffer that has been allocated to it.
  • the incident identification assistance agent 102 transmits the duplicated stream with a delta offset to the duplicated virtual machine VM1 'with respect to sending the stream to the network.
  • VM1 virtual machine the incident identification assistance agent 102 delays the flow of data so that it is transmitted to the duplicated machine VM1 after a delta shift.
  • the delta offset is expressed by means of a duration, in seconds, for example.
  • a data stream is transmitted to the virtual machine VM1 on a date T0
  • the same duplicated data stream is transmitted by the agent 102 to help identify incidents on a date T0 + delta.
  • the delta offset is set to a value less than twenty seconds. Indeed, it is estimated that beyond this, there are risks of introducing malfunctions inherent to a system access to the internal clock of the machine. For example, it is customary when starting an operating system to take into account the expiration of deadlines (called "timeout" in English) specific to start and stop startup if such a period expires.
  • Setting the delta offset to a value greater than twenty seconds may systematically trigger a timeout at the second virtual machine VMl 'and render it inoperative. It is also known that some system commands take into account the processing time of an order. This is the case for example of the "ping" command, intended to verify that a machine is accessible. The maximum value of twenty seconds has been determined empirically. It is understood that a small variation of this upper bound can be tolerated.
  • the delta offset is expressed in terms of a number of nbF flows.
  • the duplicated flow is transmitted to the second virtual machine VM1 'at a time following T1 such that during the duration T1 - T0, nbF flow, corresponding to the processing of nbF interrupts, were transmitted to VMl virtual machine.
  • the incident identification assistance agent 102 stores, in the order in which they arrive, nbF-data stream corresponding to the processing of nbF-interrupts.
  • the agent 102 sends to the second virtual machine VMl 'the data stream that has remained in its memory the longest.
  • the offset is therefore expressed in a number of flows. It is thus considered that a maximum of ten thousand data streams can be stored. Obviously, it is understood that this value, fixed empirically may vary slightly. It is understood that, whatever the way of expressing the delta offset, the duplicated machine VM1 'is impacted in the same way as the virtual machine VM1 during the processing of an interrupt, but at a later time, defined by the offset delta.
  • an incident is detected at the virtual machine VM1.
  • an incident here corresponds to an event that is not part of the normal and expected operation of the virtual machine VMl.
  • the virtual machine stops working, or VMl virtual machine suffers a significant decrease in performance.
  • the processing of the duplicated flows by the incident identification assistance agent 102 also stops, that is to say that the duplicated flows stored in the buffer memory and waiting for sending to the duplicated machine VMl 'are not transmitted to the duplicated machine VMl'; they remain stored in the buffer. There is therefore a pause of the second virtual machine VMl '. This incident is reported to a security operator (not shown).
  • a next step E8 of stepwise processing the security operator intervenes manually in the environment 10, and more precisely at the level of the agent 102 to assist in the identification of incidents.
  • the security operator successively unlocks the flows of Duplicate data and stored in the buffer of the agent 102.
  • the duplicate data streams can be transmitted one by one, or in groups of several, to the duplicated VMM virtual machine, in the manner of a debugger.
  • the operator also observes the impacts of one or more flows on the VM1 duplicated machine at the level of the system logs available to him.
  • the execution step is therefore set to one.
  • the execution step comprises several data streams. Thus, several data streams are transmitted simultaneously by the agent 102 to the duplicated virtual machine VM1.
  • agent 102 for assistance in the identification of incidents intervenes at the duplicated machine VMl 'only to transmit data streams from the execution of an interruption. Agent 102 is therefore not intrusive. This aspect is important since the method of assisting in the identification of incidents requires keeping the states of the virtual machine VM1 and the duplicated machine VM1 'the same. No action must therefore be undertaken on the duplicate machine VMl 'at the risk of generating a different state on the duplicated machine VMl'. With the security monitoring solution described here, a client is assured that his virtual machine is never compromised since the agent 102 for incident identification assistance is not installed on the virtual machine VM1. customer.
  • the steps E5 for duplication of flow, sending and storage, E6 for processing a duplicated flow are iterated for each interrupt, as long as no incident is detected.
  • the invention is described here in the case where a customer has subscribed to an offer type IaaS.
  • the invention is however not limited to this type of offer and also applies when a customer subscribes to a PaaS type offer.
  • the security solution proposed here is particularly interesting in the case of an IaaS architecture.
  • the cloud service provider provides the customer with resources and the client then installs the software he wants, including the operating system.
  • the cloud service provider has complete control over the virtual machines of the architecture and is assured of being able to deploy the agent 102 to assist in the identification of incidents.
  • a device for assisting the identification of incidents on a virtual machine will now be described with reference to FIG.
  • An incident identification assistance device 10 is a computer equipment such as a terminal or a server. According to the architecture model described in connection with FIG. 1, the device is a host server 10, adapted to host client virtual machines, for example the VM1 virtual machine.
  • the incident identification assistance device 10 comprises a virtualization layer 10-2 intended to house a hypervisor 101.
  • the hypervisor 101 comprises an incident identification assistance module 102 able to implement implement some of the steps of the method described above and is adapted to virtualize resources of the host server 10 to provide the virtual machine VM1 the resources it needs.
  • the incident identification assistance device 10 conventionally comprises:
  • microprocessor 103 or "CPU” (of the “Central Processing Unit"), intended to load instructions into memory, to execute them, to perform operations,
  • RAM Random Access Memory
  • a storage memory 105 of "ROM” or “EEPROM” type (of English “Read-Only Memory” and “Electronically-Erasable Programmable Read-Only Memory”).
  • the storage memory 105 is arranged to store code instructions intended to implement the steps of the incident detection assistance method as described above;
  • the communication interfaces 106 are adapted to facilitate communication between the incident identification assistance agent 102, the VM1 virtual machine and its operating system OS1, and the virtual VMM 'virtual machine.
  • the microprocessor 103, the memories 104, 105, the communication interfaces 106 are hardware resources that belong to the hardware execution layer 10. -1. These resources are intended to be virtualized by the hypervisor 101 and made available to the virtual machines VM1, VM1 'and the agent 102 for helping to identify incidents 102 in virtualized form. It is indeed the hypervisor 101 that allocates the memory area to the agent 102.
  • the incident identification assistance device 10 also comprises:
  • reception means 107 arranged to receive from the operating system of the virtual machine VM1 at least one machine instruction corresponding to an interruption at the level of the operating system OS1 of the virtual machine VM1, said interruption being consecutive to an event occurring at the virtual machine VMl.
  • the reception means 107 are arranged to implement the step E3 of the incident identification assistance method described above;
  • the execution means are arranged to implement step E4 of the incident identification assistance method described above;
  • means 109 for duplication and transmission arranged to duplicate the data stream obtained by the execution means 108 in a second stream, or duplicated stream, for transmitting the stream to the OS1 operating system of the virtual machine VM1 and to memorize the duplicate flow.
  • the means 109 for duplication and transmission are arranged to implement step E5 of the method described above;
  • the stream transmission means 110 for transmitting the duplicated stream, arranged to transmit the duplicated stream to the operating system OS1 'of a second virtual machine VM1' hosted by the device 10, with a delta offset with respect to the transmission of the stream to the system OS1 operating the virtual machine VMl, the second virtual machine VMl 'being distinct from the virtual machine, an incident occurring on the virtual machine occurring on the second machine at least with the delta offset.
  • the stream transmission means 110 are arranged to implement the step E6 of the incident identification assistance method described above.
  • the incident decision support device 10 also comprises: means 111 for detecting and pausing (in dashed lines in FIG. 3), arranged to detect an incident on the virtual machine VM1, and to pause the execution of the second virtual machine VM1 ',
  • transmission and observation means 112 (in dashed lines in FIG. 3), arranged to transmit data streams to the virtual VM1 'duplicate machine step by step, and to observe at each step and from logs of executing the impact of one of said streams transmitted on the duplicated virtual machine.
  • the security agent 102 and the hypervisor 101 are preferably software modules comprising software instructions for executing the steps of the previously described problem identification assistance method.
  • the invention therefore also relates to:
  • the software modules can be stored in, or transmitted by, a data carrier.
  • This may be a hardware storage medium, for example a CD-ROM, a magnetic diskette or a hard disk, or a transmission medium such as a signal or a telecommunications network.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Quality & Reliability (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Hardware Redundancy (AREA)

Abstract

L'invention concerne un procédé d'aide à l'identification d'incidents sur une machine virtuelle (VM1) hébergée par un système hôte (10), la machine virtuelle comprenant un système d'exploitation (OS1) communiquant avec un hyperviseur (101) du système hôte, ledit hyperviseur s'interfaçant entre le système d'exploitation et des ressources matérielles du système hôte, ledit procédé comprenant les étapes suivantes, mises en œuvre par l'hyperviseur : - réception (E3), en provenance du système d'exploitation, d'au moins une instruction machine correspondant à une interruption au niveau du système d'exploitation, ladite interruption étant consécutive à un événement survenu au niveau de la machine virtuelle, - exécution (E4) de l'instruction par l'hyperviseur au moyen des ressources matérielles du système hôte et transmission (E5) au système d'exploitation d'un flux de données comprenant le résultat de l'exécution de l'interruption, caractérisé en ce que le flux de données est dupliqué (E5) en un second flux, ledit second flux étant transmis au système d'exploitation d'une deuxième machine virtuelle (VM1') avec un décalage par rapport à la transmission du flux au système d'exploitation de la machine virtuelle, la deuxième machine virtuelle étant distincte de la machine virtuelle, un incident survenant sur la machine virtuelle ne survenant sur la deuxième machine qu'au moins avec le décalage.

Description

Procédé d'aide à l'identification d'incidents dans une architecture d'informatique dans le nuage
La présente invention concerne un procédé d'aide à l'identification d'incidents sur une machine virtuelle comprise dans un environnement informatique virtualisé, c'est-à-dire rendu virtuel.
Elle trouve une application particulièrement intéressante dans la sécurisation des systèmes informatiques dont l'architecture est basée sur des ressources informatiques dématérialisées, mises à disposition d'utilisateurs qui y accèdent à distance. Une telle architecture est plus connue sous le nom d' architecture en « cloud Computing », ou architecture « d'informatique dans le nuage ».
Une architecture en cloud Computing comprend habituellement au moins un serveur hôte qui possède des ressources matérielles sur lesquelles s'appuie un service en cloud Computing offert par un fournisseur de services à un ou des clients. Le fournisseur de services met à disposition du client une ou des machines virtuelles qui constituent l'environnement d'exécution du service propre au client. La ou les machines virtuelles utilisent les ressources du serveur hôte pour s'exécuter.
Il est connu que lorsqu'un incident survient sur une machine virtuelle, il est très difficile d'identifier son origine. Un incident est un événement qui ne fait pas partie du fonctionnement standard et attendu de la machine virtuelle et qui peut provoquer une interruption de son exécution, une diminution de la qualité du service rendu par la machine virtuelle, etc. Il existe en effet peu d'éléments et d'outils qui permettent d'identifier la cause d'un incident dans un environnement en cloud Computing. Tout au plus il est possible de consulter un ensemble de journaux systèmes. Cependant ces journaux sont génériques et à grains grossiers. Ils sont insuffisants pour l'identification précise de l'incident. Une machine qui a subi un incident doit souvent être laissée en l'état afin de ne perdre aucune information qui pourrait se trouver en mémoire vive et sui serait pertinente pour identifier l'incident. Le service que rendait la machine virtuelle est donc interrompu, ce qui peut poser problème en termes de disponibilité du service lorsqu' aucune méthode de redondance n'a été mise en place.
Un des buts de l'invention est de remédier à des insuffisances/inconvénients de l'état de la technique et/ou d'y apporter des améliorations.
A cette fin, l'invention propose un procédé d'aide à l'identification d'incidents sur une machine virtuelle hébergée par un système hôte, la machine virtuelle comprenant un système d'exploitation communiquant avec un hyperviseur du système hôte, ledit hyperviseur s'interfaçant entre le système d'exploitation et des ressources matérielles du système hôte, ledit procédé comprenant les étapes suivantes, mises en œuvre par l'hyperviseur :
- réception, en provenance du système d'exploitation, d'au moins une instruction machine correspondant à une interruption au niveau du système d'exploitation, ladite interruption étant consécutive à un événement survenu au niveau de la machine virtuelle,
- exécution de l'instruction par l'hyperviseur au moyen des ressources matérielles du système hôte et transmission au système d'exploitation d'un flux de données comprenant le résultat de l'exécution de l'interruption,
caractérisé en ce que le flux de données est dupliqué en un second flux, ledit second flux étant transmis au système d'exploitation d'une deuxième machine virtuelle avec un décalage par rapport à la transmission du flux au système d'exploitation de la machine virtuelle, la deuxième machine virtuelle étant distincte de la machine virtuelle, un incident survenant sur la machine virtuelle ne survenant sur la deuxième machine qu'au moins avec le décalage.
Le procédé décrit ici permet ainsi de disposer d'une deuxième machine virtuelle qui se trouve exactement dans le même état que la machine virtuelle mais avec un décalage dans le passé. Cela permet d'observer finement ce qui se passe entre la survenue effective d'un incident sur la machine virtuelle et la survenue de ce même incident sur la deuxième machine virtuelle, qui n'intervient qu'après le décalage. Par construction, les machines virtuelles sont distinctes : bien qu'ayant les mêmes caractéristiques, elles sont installées sur des pages mémoire distinctes. Il n'y a donc aucun partage de charge entre les machines virtuelles, ni aucune redondance. La machine virtuelle ne subit donc aucun effet de bord du fait de la duplication du flux et du traitement effectué sur la deuxième machine virtuelle.
Ainsi, grâce au procédé décrit, un fournisseur de solutions de virtualisation peut proposer une nouvelle offre de sécurité et d'investigation qui n'existe pas actuellement. L'analyse des systèmes compromis dans des environnements virtuels est une opération coûteuse financièrement et en temps. Une telle offre est donc indéniablement un plus.
Selon un exemple de réalisation, le procédé comprend en outre les étapes de :
- détection d'un incident sur la machine virtuelle et mise en pause de l'exécution de la deuxième machine virtuelle,
- transmission pas à pas des flux de données à la machine virtuelle dupliquée, et observation à chaque pas et à partir de journaux d'exécution de l'impact d'un desdits flux transmis sur la machine virtuelle dupliquée.
Dans cet exemple, il est possible d'interrompre l'envoi des flux de données destinés à être transmis en décalé à la deuxième machine virtuelle dès lors qu'un incident est détecté au niveau de la machine virtuelle. Par ailleurs, il est possible de transmettre pas à pas les flux de données à la deuxième machine virtuelle afin d'observer, à chaque pas, le résultat de l'exécution de l'interruption compris dans chacun des flux de données sur cette machine. Ce fonctionnement est assimilé à celui d'outils informatiques connus sous le nom de débogueurs (ou « debugger » en anglais). Les débogueurs sont des logiciels qui permettent à un développeur d'analyser des bugs d'un programme en offrant la possibilité d'exécuter ce programme pas à pas, de mettre en place des points d'arrêt sur des conditions ou des lignes de programmes, d'afficher la valeur de variables à tout moment, voire de changer leur valeur afin de cerner la cause d'un incident. Cependant, dans un environnement en cloud Computing, il n'est pas envisageable de disposer d'un tel outil. En effet, dans un environnement en cloud Computing, il ne s'agit plus d'analyser l'exécution d'un programme en particulier mais d'un méta-programme que constitue la machine virtuelle et qui correspond à une pluralité de programmes. Ainsi, pour une machine virtuelle, il faut pouvoir tenir compte de tous les événements possibles, par exemple, des clics de souris, des entrées clavier, etc. La quantité d'informations qui est générée est alors tellement importante qu'il est difficile, voire impossible pour un opérateur humain d'analyser autant d'informations. Avec le procédé décrit ici, on offre un outil de débogage à grain fin.
Dans un exemple de réalisation, le décalage est exprimé par un intervalle de temps. Exprimer le décalage par une durée constitue une première variante de réalisation. Dans un exemple de réalisation de cette variante, l'intervalle de temps est inférieur ou égal à 20 secondes.
On estime qu'au-delà de vingt secondes, il y a des risques d'introduire des dysfonctionnements inhérents à un accès du système d'exploitation à l'horloge interne d'une machine virtuelle. Par exemple, il est habituel lors du démarrage d'un système d'exploitation de tenir compte de l'expiration de délais (on parle de « timeout » en anglais) et de stopper le démarrage si un tel délai expire. Fixer le décalage à une valeur supérieure à vingt secondes risque de déclencher systématiquement une expiration de délai et rendre inopérante la deuxième machine virtuelle. Il est également connu que certaines commandes tiennent compte du temps de traitement d'une commande. C'est le cas par exemple de la commande « ping », destinée à vérifier qu'une machine est accessible. La valeur maximale de vingt secondes a été déterminée de manière empirique. On comprend qu'une petite variation de cette borne supérieure peut être tolérée.
Dans un autre exemple de réalisation, le décalage est exprimé par un nombre de flux de données, un flux de données comprenant le résultat de l'exécution d'une interruption par le système d'exploitation de la machine virtuelle. Exprimer le décalage en termes de nombre d'instructions constitue une deuxième variante de réalisation.
Dans un exemple de réalisation de cette deuxième variante, le nombre de flux de données est inférieur ou égal à 10000.
Cette valeur est représentative d'un délai de vingt secondes tel que prévu précédemment. Exprimer le décalage sous forme de nombre de flux de données correspondant chacun au résultat de l'exécution d'une interruption peut faciliter la planification de l'observation de l'exécution pas à pas de la deuxième machine virtuelle en choisissant des pas d'exécution fonction d'un nombre d'instructions. Une telle valeur peut être plus facile à quantifier dans le cadre de la définition d'un processus d'identification d'incidents.
Dans un exemple de réalisation, un pas d'observation comprend au moins deux flux de données.
Un pas d'observation qui comprend plusieurs flux de données permet à l'opérateur de grouper le traitement de plusieurs flux de données qui ne sont pas problématiques.
L'invention porte également sur un serveur mettant en œuvre une entité d'aide à l'identification d'incidents survenant sur une machine virtuelle hébergée par le serveur, ladite entité résidant dans une couche virtuelle du serveur, ladite machine virtuelle comprenant un système d'exploitation communiquant avec un hyperviseur du serveur, ledit hyperviseur s'interfaçant entre le système d'exploitation et des ressources matérielles du serveur, ledit serveur comprenant :
- des moyens de réception, agencés pour recevoir en provenance du système d'exploitation, au moins une instruction machine correspondant à une interruption au niveau du système d'exploitation, ladite interruption étant consécutive à un événement survenu au niveau de la machine virtuelle,
- des moyens d'exécution, agencés pour exécuter l'instruction au moyen des ressources matérielles du système hôte
- des moyens de duplication et de transmission , agencés pour dupliquer le flux de données en un second flux, et pour transmettre au système d'exploitation d'un flux de données comprenant le résultat de l'exécution de l'interruption,
- des moyens de transmission de flux, agencés pour transmettre le second flux au système d'exploitation d'une deuxième machine virtuelle hébergée par le serveur, avec un décalage par rapport à la transmission du flux au système d'exploitation de la machine virtuelle, la deuxième machine virtuelle étant distincte de la machine virtuelle, un incident survenant sur la machine virtuelle ne survenant sur la deuxième machine qu'au moins avec le décalage. L'invention concerne également un programme d'ordinateur sur un support de données et chargeable dans la mémoire d'un ordinateur, le programme comprenant des instructions de code pour l'exécution des étapes du procédé d'aide à l'identification d'incidents sur une machine virtuelle tel que décrit précédemment, lorsque le programme est exécuté sur ledit ordinateur
L'invention concerne aussi un support de données dans lequel est enregistré le programme décrit ci-dessus.
D'autres caractéristiques et avantages de la présente invention seront mieux compris de la description et des dessins annexés parmi lesquels :
- la figure 1 est une représentation schématique d'un modèle d'architecture en cloud Computing adapté pour la mise en œuvre du procédé d'aide à l'identification d'un incident sur une machine virtuelle, selon un exemple de réalisation de l'invention ;
- la figure 2 présente les étapes du procédé d'aide à l'identification d'un incident sur une machine virtuelle, selon un premier exemple de réalisation de l'invention ;
- la figure 3 est une représentation schématique d'un serveur hébergeant une entité d'aide à l'identification d'incidents sur une machine virtuelle, selon un exemple de réalisation de l'invention. Un modèle d'architecture adapté pour la mise en œuvre d'un procédé d'aide à l'identification d'incidents sur une machine virtuelle comprise dans un environnement informatique virtualisé, selon un exemple de réalisation va maintenant être décrit en relation avec la figure 1.
Habituellement, une architecture d'informatique dans le nuage (on parle habituellement d'architecture en « cloud Computing »), est conforme à un modèle qui comprend plusieurs couches d'exécution. Différents modèles existent. Un exemple de modèle d'architecture en cloud Computing pour une architecture qui comprend un serveur hôte 10 est décrit en relation avec la figure 1.
Le serveur hôte 10 comprend ainsi une première couche d'exécution, ou couche d'exécution matérielle 10-1. Cette couche d'exécution matérielle 10-1 comprend un ensemble de ressources matérielles rl, r2, r3, r4, etc., du serveur hôte 10. Une ressource matérielle correspond par exemple à de la mémoire, à une interface réseau, à un micro-processeur, etc. Une deuxième couche d'exécution est une couche de virtualisation 10-2. La couche de virtualisation 10-2 est adaptée pour présenter à un ou des systèmes d'exploitation de machines virtuelles, par exemple le système d'exploitation OSl d'une machine virtuelle VMl, d'une couche virtuelle 10-3, un espace de ressources virtuelles, construit à partir d'un espace de ressources physiques du serveur hôte 10, en l'espèce l'espace des ressources rl, r2, r3, r4, etc. de la couche d'exécution matérielle 10-1. La couche de virtualisation 10-2 est mise en œuvre par un module de virtualisation appelé habituellement hyperviseur 101 qui gère l'allocation des ressources matérielles entre les différentes instances de machines virtuelles et qui met à disposition des machines virtuelles ces ressources virtualisées. La couche de virtualisation 10-2 est adaptée également pour la création, l'instanciation, la libération, le placement de machines virtuelles exécutées de manière concurrente sur une même machine physique, ici le serveur hôte 10. Enfin, une troisième couche d'exécution est la couche virtuelle 10-3. Les ressources associées à cette couche sont les machines virtuelles, par exemple la machine virtuelle VMl, qui s'exécutent dans l'environnement virtuel mis à disposition par le serveur hôte 10 en tant que machine physique. Les machines virtuelles sont par exemple des machines virtuelles de clients qui peuvent comprendre des données ou du code sensibles à protéger.
Lorsqu'une machine virtuelle est démarrée et en cours d'exécution, une action au niveau de la machine virtuelle, est gérée de manière classique par le système d'exploitation de la machine virtuelle sous forme d'interruption. Une action est par exemple le déplacement de la souris par un utilisateur, la sauvegarde d'un fichier. Une interruption consiste à interrompre l'exécution normale d'un programme par le microprocesseur de manière à exécuter un autre programme, ou routine d'interruption, par exemple celui destiné à prendre en compte l'action de l'utilisateur sur la machine virtuelle. La routine d'interruption comprend des instructions machines, c'est-à-dire des instructions bas-niveau, en langage machine, tel qu'en assembleur. Ces instructions bas-niveau impliquent des ressources, telles que de la mémoire, des interfaces, des périphériques, etc. L'hyperviseur 101 qui met à disposition de la machine virtuelle des ressources virtualisées est un intermédiaire entre le système d'exploitation de la machine virtuelle et les ressources matérielles de la couche d'exécution matérielle 10-1 du système hôte 10. Ainsi, lors d'une interruption au niveau du système d'exploitation OS1 de la machine virtuelle VMl, l'hyperviseur 101 reçoit les instructions machine du système d'exploitation OS1 qui impliquent les ressources virtualisées et commande l'exécution de ces instructions à partir des ressources matérielles du système hôte 10. Il transmet ensuite au système d'exploitation OS1 le résultat de cette exécution sous forme d'un flux de données comprenant le résultat de cette exécution. Ce flux comprend ainsi des événements à destination des périphériques d'entrée/sortie virtuels utilisés par la machine virtuelle VMl. Dans le cas du déplacement de la souris, le traitement de l'interruption provoque ainsi le déplacement effectif de la souris sur un écran associé à la machine virtuelle VMl. Il est connu que l'exécution de la routine d'interruption ne peut être interrompue, on dit que les instructions de la routine sont exécutées de manière atomique.
L'hyperviseur 101 gère l'accès du système d'exploitation OS1 de la machine virtuelle VMl à l'architecture matérielle sous-jacente. Selon l'exemple de réalisation décrit, la couche de virtualisation 10-2, plus précisément l'hyperviseur 101 comprend un module d'aide à l'identification d'incidents 102, appelé agent, adapté pour permettre à un opérateur humain d'identifier l'origine d'un incident sur une machine virtuelle, par exemple la machine virtuelle VMl lorsque l'agent 102 est associé à la machine virtuelle VMl par l'hyperviseur 101. Un incident est un événement qui ne fait pas partie du fonctionnement standard et attendu d'un service, d'une application, ou plus généralement d'une machine virtuelle, et qui provoque, au niveau de l'exécution de la machine virtuelle, une interruption de son exécution, ou une diminution de la qualité de service. Des exemples d'incident sont une application qui s'exécute au niveau de la machine virtuelle et qui est non disponible, une erreur programme, un nombre excessif d'entrées/sorties disque, un système hors service, etc. L'agent d'aide à l'identification d'incidents 102 est un module logiciel autonome comprenant des instructions de code pour mettre en œuvre certaines des étapes du procédé d'aide à l'identification d'incidents. Le module d'aide à la détection d'incidents 102 est agencé pour aider un opérateur à identifier l'origine d'un incident sur la machine virtuelle VMl. A cette fin, l'hyperviseur 101 est agencé pour dupliquer la machine virtuelle VMl en une deuxième machine virtuelle VMl ' (en pointillés sur la figure 1). La deuxième machine VMl ' possède les mêmes caractéristiques que la machine VMl : même adresse réseau, même adresse MAC, etc. Cependant, elle est installée sur des pages mémoire distinctes de celles de la machine VMl. Elle est donc différente de la machine VMl. L'hyperviseur 101 est également agencé pour allouer à l'agent d'aide à l'identification d'incidents 102 une zone mémoire tampon (on parle de « buffer » en anglais) sur une page mémoire distincte des pages mémoire allouées aux machines virtuelles VMl et VMl' et pour transmettre à l'agent 102 un flux de données comprenant le résultat de l'exécution d'une interruption au niveau de la machine virtuelle VMl. L'agent d'aide à l'identification d'incidents 102 est agencé pour dupliquer un flux de données reçu de l'hyperviseur, pour l'envoyer d'une part à la machine VMl et pour le mémoriser temporairement, avant de le transmettre à la deuxième machine virtuelle VMl '. Ainsi, la deuxième machine virtuelle VMl ' se comporte de la même manière que la machine virtuelle VMl mais avec un décalage inhérent au temps pendant lequel le flux est gardé en mémoire par l'agent 102. L'agent 102 temporise donc les flux de données vers la deuxième machine VMl' . L'agent 102 est agencé également pour mettre en pause l'exécution de la deuxième machine virtuelle, sur commande d'un opérateur ou sur détection d'un incident sur la machine virtuelle VMl. L'agent 102 est également agencé pour interagir avec l'opérateur et pour transmettre pas à pas les flux mémorisés à la deuxième machine VM1 '. Ainsi, l'opérateur peut exécuter pas à pas, c'est-à-dire interruption par interruption, les flux de données correspondant aux résultats des interruptions et identifier l'origine de l'incident, en consultant des journaux dont il dispose et en observant les impacts du traitement d'une interruption sur la deuxième machine virtuelle.
De même qu'il existe différents modèles d'architecture, on recense également différentes offres de services en cloud Computing. On connaît ainsi un premier modèle, appelé « SaaS » (de l'anglais « Software-as-a-Service ») dans lequel un fournisseur de services met à disposition de l'utilisateur une pile logicielle complète, depuis le matériel jusqu'aux applications. On connaît un deuxième modèle, appelé « PaaS » (de l'anglais « Platform-as-a- Service »), dans lequel les utilisateurs déploient leurs propres applications à l'aide d'environnements et d'outils mis à disposition par le fournisseur de services. Enfin, on connaît un troisième modèle, appelé « IaaS » (de l'anglais « Infrastructure-as-a-Service ») dans lequel le fournisseur de services met à disposition des utilisateurs des ressources de calcul, de communication ou de stockage. Les utilisateurs peuvent alors déployer et exécuter n'importe quel logiciel, y compris leur propre système d'exploitation, qui exploite les ressources ainsi mises à disposition. Dans l'exemple de réalisation décrit ici, on suppose qu'un client souscrit à une offre de type IaaS. Les étapes d'un procédé d'aide à l'identification d'incidents sur une machine virtuelle comprise dans un environnement informatique virtualisé, selon un premier exemple de réalisation, vont maintenant être décrites en relation avec la figure 2.
On suppose que l'architecture en cloud Computing est conforme au modèle décrit en relation avec la figure 1.
On suppose qu'un client, non représenté, a configuré une machine virtuelle VM1 en précisant auprès d'un fournisseur de services les ressources dont il souhaitait disposer sur le serveur 10 du fournisseur de services en termes par exemple de taille mémoire, de type de carte mémoire, de nombre de processeurs et de cartes réseau, de version de machine virtuelle, etc. La configuration est ensuite utilisée par le fournisseur de services afin de permettre à l'hyperviseur 101 de démarrer la machine virtuelle VM1 mise à disposition du client en allouant les ressources définies par configuration. Lors d'une libération ultérieure de la machine virtuelle VM1, c'est-à-dire en fin d'exécution de la machine virtuelle VM1 dans l'environnement d'exécution, une image mémoire de la machine virtuelle VM1 est mémorisée dans une base de données (non représentée). Les modifications apportées par le client à la machine virtuelle VM1 lors de l'exécution de celle-ci dans l'environnement d'exécution sont ainsi prises en compte lors d'un redémarrage ultérieur.
Dans une étape initiale E0 de démarrage ou de redémarrage de la machine virtuelle, la machine virtuelle VMl est démarrée ou redémarrée par le fournisseur de services. Ce démarrage signifie que la machine virtuelle VMl telle que mémorisée ou configurée est chargée par l'hyperviseur 101 sur le serveur hôte 10. Toutes les ressources paramétrées pour la machine VMl sont alors fournies par l'hyperviseur 101 à la machine virtuelle VMl pour que celle-ci s'exécute. Le client peut alors disposer de sa machine virtuelle VMl afin d'installer tous les logiciels dont il a besoin pour son activité.
Une fois la machine virtuelle VMl démarrée sur le système hôte 10 par l'hyperviseur
101, dans une étape El de duplication, l'hyperviseur 101 duplique la machine virtuelle VMl du client. Cette duplication consiste à créer une deuxième machine virtuelle VMl ' similaire à la machine virtuelle VMl du client mais cependant distincte. « Similaire » signifie que la machine dupliquée VMl ' possède les mêmes caractéristiques que la machine virtuelle VMl du client : même adresse réseau, même adresse MAC ; elle dispose des mêmes quantités de ressources, etc. Elle est cependant installée sur des pages mémoire différentes de celles utilisées par la machine virtuelle VMl. La machine dupliquée VMl ' est donc distincte de la machine virtuelle VMl mais se comporte de façon similaire à la machine virtuelle VMl dès lors qu'elle reçoit les mêmes flux de données. Par ailleurs l'hyperviseur 101 alloue à l'agent d'aide à l'identification d'incidents 102 une zone mémoire tampon sur une page mémoire distincte de celles allouées à la machine virtuelle VMl et à la machine dupliquée VMl '. L'indépendance de cette zone mémoire par rapport aux zones mémoire des machines virtuelles garantit l'indépendance de l'agent 102 d'aide à l'identification d'incidents par rapport au fonctionnement des machines virtuelles VMl et VMl' . Dans une variante de réalisation, la deuxième machine virtuelle VMl ' est démarrée en même temps que la machine VMl, au cours de l'étape E0 de démarrage ou de redémarrage, à partir de la configuration de la machine virtuelle VMl. De même, dans une variante de réalisation, la zone mémoire tampon est allouée par l'hyperviseur 101 à l'agent 102 durant l'étape E0 de démarrage ou de redémarrage, indépendamment du démarrage ou redémarrage de la machine virtuelle VMl.
Dans une étape E2 d'association de l'agent, l'agent d'aide à l'identification d'incidents
102 est associé par l'hyperviseur 101 à la machine virtuelle dupliquée VMl '. Au terme de cette association, l'agent 102 est apte à superviser l'exécution de la machine virtuelle dupliquée VMl' afin de fournir une aide à l'identification d'incidents lorsque ceux-là surviennent sur la machine virtuelle VMl. Dans une étape E3 de réception d'une interruption, consécutive à un événement survenu au niveau de la machine virtuelle VM1, l'hyperviseur 101 reçoit du système d'exploitation OS1 de la machine virtuelle VM1 une séquence d'au moins une instruction machine correspondant à une routine d'interruption. Plus précisément, un événement au niveau de la machine virtuelle VM1 du client déclenche une interruption au niveau du système d'exploitation OS1 de la machine virtuelle VM1. Cette interruption correspond à la séquence d'instructions. L'événement qui provoque une interruption est par exemple le déplacement de la souris par le client, une demande de sauvegarde de fichier, etc.
Dans une étape E4 d'exécution de l'interruption, le système d'exploitation OS1 de la machine virtuelle VM1 commande l'exécution de la séquence d'instructions. Les instructions de la séquence sont exécutées sur les ressources virtualisées contrôlées par l'hyperviseur 101 qui fait appel aux ressources matérielles sous-jacentes. C'est donc l'hyperviseur 101, qui met à disposition de la machine virtuelle VM1 les ressources virtualisées, qui commande l'exécution de la séquence d'instructions au moyen des ressources matérielles du système hôte 10. Le résultat de l'exécution de cette séquence d'instructions constitue un flux de données transmis à l'agent 102 d'aide à l'identification d'incidents et destiné à être transmis à la machine virtuelle VM1.
Dans une étape E5 de duplication de flux, d'envoi et de mémorisation, l'agent 102 d'aide à l'identification d'incidents duplique le flux reçu de l'hyperviseur 101 et destiné à la machine virtuelle VM1, et obtient un deuxième flux appelé flux dupliqué. Il transmet alors le flux de manière classique à la machine virtuelle VM1 en tant que résultat du traitement de l'interruption et mémorise le flux dupliqué dans la mémoire tampon qui lui a été allouée.
Dans une étape suivante E6 de traitement du flux dupliqué, l'agent 102 d'aide à l'identification d'incidents transmet à la machine virtuelle dupliquée VM1' le flux dupliqué avec un décalage delta par rapport à l'envoi du flux à la machine virtuelle VM1. En d'autres termes, l'agent 102 d'aide à l'identification d'incidents temporise le flux de données de manière à ce qu'il soit transmis à la machine dupliquée VM1 après un décalage delta.
Dans un premier exemple de réalisation, le décalage delta est exprimé au moyen d'une durée, en secondes par exemple. Ainsi, lorsqu'un flux de données est transmis à la machine virtuelle VM1 à une date T0, le même flux de données dupliqué est transmis par l'agent 102 d'aide à l'identification d'incidents à une date T0 + delta. Le décalage delta est fixé à une valeur inférieure à vingt secondes. En effet, on estime qu'au-delà, il y a des risques d'introduire des dysfonctionnements inhérents à un accès du système à l'horloge interne de la machine. Par exemple, il est habituel lors du démarrage d'un système d'exploitation de tenir compte de l'expiration de délais (on parle de « timeout » en anglais) propres à des programmes de démarrage et de stopper le démarrage si un tel délai expire. Fixer le décalage delta à une valeur supérieure à vingt secondes risque de déclencher systématiquement une expiration de délai au niveau de la deuxième machine virtuelle VMl ' et de la rendre inopérante. Il est également connu que certaines commandes systèmes tiennent compte du temps de traitement d'une commande. C'est le cas par exemple de la commande « ping », destinée à vérifier qu'une machine est accessible. La valeur maximale de vingt secondes a été déterminée de manière empirique. On comprend qu'une petite variation de cette borne supérieure peut être tolérée.
Dans un deuxième exemple de réalisation, le décalage delta est exprimé en termes d'un nombre de flux nbF. Ainsi, lorsque le flux de données est transmis à la machine virtuelle VMl à l'instant T0, le flux dupliqué est transmis à la deuxième machine virtuelle VMl' à un instant suivant Tl tel que pendant la durée Tl - T0, nbF flux, correspondant au traitement de nbF interruptions, ont été transmis à la machine virtuelle VMl. En d'autres termes, l'agent 102 d'aide à l'identification d'incidents mémorise, dans l'ordre dans lequel ils arrivent, nbF-flux de données, correspondant au traitement de nbF-interruptions. A l'arrivée du nbF-plus unième flux de données, correspondant au traitement de la nbF-plus unième interruption, l'agent 102 envoie à la deuxième machine virtuelle VMl ' le flux de données qui est resté le plus longtemps dans sa mémoire. Dans cet exemple, le décalage est donc exprimé en un nombre de flux. On considère ainsi que l'on peut stocker un maximum de dix mille flux de données. Evidemment, on comprend que cette valeur, fixée de manière empirique peut légèrement varier. On comprend que, quel que soit la façon d'exprimer le décalage delta, la machine dupliquée VMl ' est impactée de la même façon que la machine virtuelle VMl lors du traitement d'une interruption, mais à un instant ultérieur, défini par le décalage delta.
Dans une étape E7 de survenue d'un incident, on suppose qu'un incident est détecté au niveau de la machine virtuelle VMl. On rappelle qu'un incident correspond ici à un événement qui ne fait pas partie du fonctionnement normal et attendu de la machine virtuelle VMl. Par exemple, la machine virtuelle arrête de fonctionner, ou la machine virtuelle VMl subit une diminution importante de ses performances. Dans ce cas, le traitement des flux dupliqués par l'agent 102 d'aide à l'identification d'incidents s'arrête également, c'est-à-dire que les flux dupliqués mémorisés dans la mémoire tampon et en attente d'envoi à la machine dupliquée VMl' ne sont pas transmis à la machine dupliquée VMl' ; ils restent stockés dans la mémoire tampon. Il y a donc une mise en pause de la deuxième machine virtuelle VMl' . Cet incident est signalé à un opérateur de sécurité (non représenté).
Dans une étape suivante E8 de traitement pas à pas, l'opérateur de sécurité intervient manuellement dans l'environnement 10, et plus précisément au niveau de l'agent 102 d'aide à l'identification d'incidents. L'opérateur de sécurité débloque successivement les flux de données dupliqués et stockés dans la mémoire tampon de l'agent 102. Ainsi, les flux de données dupliqués peuvent être transmises un à un, ou par groupe de plusieurs, à la machine virtuelle dupliquée VMl, à la manière d'un débogueur. L'opérateur observe également les impacts d'un ou de plusieurs flux sur la machine dupliquée VMl ' au niveau des journaux systèmes dont il dispose. Une analyse pas à pas des impacts des flux de données sur la deuxième machine virtuelle VMl ' permet à l'opérateur de faire une analyse fine de l'incident et lui offre beaucoup plus de moyens d'identifier l'origine de l'incident sur la machine virtuelle VMl que ce que lui offrent des moyens connus. Dans l'exemple décrit ici les flux de données stockés dans la mémoire allouée à l'agent 102 d'aide à l'identification d'incidents lors de la mise en pause de l'exécution de la machine virtuelle dupliquée VMl ' sont débloqués un à un, c'est-à-dire que l'exécution de la machine virtuelle dupliquée VMl ' est mise en pause après le traitement de chaque flux de données. Le pas d'exécution est donc fixé à un. Dans un autre exemple de réalisation, le pas d'exécution comprend plusieurs flux de données. Ainsi plusieurs flux de données sont transmis simultanément par l'agent 102 à la machine virtuelle dupliquée VMl. « Simultanément » signifie qu'ils sont transmis les uns à la suite des autres, dans l'ordre dans lequel ils ont été mémorisés et la deuxième machine virtuelle VMl ' est mise en pause après traitement de ces flux. Un pas réglable permet de configurer le débogage et de débloquer des séries de flux de données qui ne sont pas problématiques.
On note qu'il n'y a aucun partage de charge entre les machines virtuelles VMl et VMl ' , ni aucune redondance puisqu'elles sont complètement distinctes, c'est-à-dire sur des pages mémoire disjointes. La machine virtuelle VMl ne subit donc aucun effet de bord du fait de la duplication du flux et du traitement effectué sur la machine virtuelle dupliquée VMl '. A noter que la duplication du flux fait partie du traitement de l'interruption. On dit qu'elle est atomique dans le sens où l'étape E5 de duplication de flux, d'envoi et de mémorisation s'exécute dans la phase non interruptible de traitement de l'interruption.
On remarque également que l'agent 102 d'aide à l'identification d'incidents n'intervient, au niveau de la machine dupliquée VMl ' que pour lui transmettre des flux de données issus de l'exécution d'une interruption. L'agent 102 n'est donc pas intrusif. Cet aspect est important puisque le procédé d'aide à l'identification d'incidents nécessite de maintenir identiques les états de la machine virtuelle VMl et de la machine dupliquée VMl '. Aucune action ne doit donc être entreprise sur la machine dupliquée VMl ' au risque de générer un état différent sur la machine dupliquée VMl '. Avec la solution de supervision de la sécurité décrite ici, un client est assuré que sa machine virtuelle n'est jamais compromise puisque l'agent 102 d'aide à l'identification d'incidents n'est pas installé sur la machine virtuelle VMl du client. Les étapes E5 de duplication de flux, d'envoi et de mémorisation, E6 de traitement d'un flux dupliqué sont itérées pour chaque interruption, tant qu'aucun incident n'est détecté.
L'invention est décrite ici dans le cas où un client a souscrit à une offre de type IaaS. L'invention n'est cependant pas limitée à ce type d'offre et s'applique également lorsqu'un client souscrit à une offre de type PaaS. On remarque cependant que la solution de sécurité proposée ici est particulièrement intéressante dans le cas d'une architecture IaaS. En effet, avec une offre IaaS, le fournisseur de services cloud met à disposition du client des ressources et le client installe ensuite les logiciels qu'il souhaite, y compris le système d'exploitation. A ce niveau, le fournisseur de services cloud a la maîtrise complète des machines virtuelles de l'architecture et est assuré de pouvoir déployer l'agent 102 d'aide à l'identification d'incidents.
Un dispositif d'aide à l'identification d'incidents sur une machine virtuelle, selon un exemple de réalisation de l'invention, va maintenant être décrit en relation avec la figure 3.
Un dispositif d'aide à l'identification d'incidents 10 est un équipement informatique tel qu'un terminal ou un serveur. Selon le modèle d'architecture décrit en relation avec la figure 1, le dispositif est un serveur hôte 10, adapté pour héberger des machines virtuelles de client, par exemple la machine virtuelle VM1. Le dispositif d'aide à l'identification d'incidents 10 comprend une couche de virtualisation 10-2 destinée à héberger un hyperviseur 101. L'hyperviseur 101 comprend un module 102 d'aide à l'identification d'incidents apte à mettre en œuvre certaines des étapes du procédé décrit précédemment et est adapté pour virtualiser des ressources du serveur hôte 10 afin de fournir à la machine virtuelle VM1 les ressources qui lui sont nécessaires.
Le dispositif d'aide à l'identification d'incidents 10 comprend de manière classique :
- un microprocesseur 103, ou « CPU » (de l'anglais « Central Processing Unit »), destiné à charger des instructions en mémoire, à les exécuter, à effectuer des opérations,
- une ensemble de mémoires, dont une mémoire volatile 104, ou « RAM » (pour « Random Access Memory ») utilisée pour exécuter des instructions de code, stocker des variables, etc.,
- une mémoire de stockage 105 de type « ROM » ou « EEPROM » (de l'anglais « Read-Only Memory » et « Electronically-Erasable Programmable Read-Only Memory). La mémoire de stockage 105 est agencée pour mémoriser des instructions de code destinées à mettre en œuvre les étapes du procédé d'aide à la détection d'incidents tel que décrit précédemment ;
- des interfaces de communication 106, agencées pour que différentes entités communiquent. En particulier, les interfaces 106 sont adaptées pour faciliter la communication entre l'agent 102 d'aide à l'identification d'incidents, la machine virtuelle VMl et son système d'exploitation OS1, et la machine virtuelle dupliquée VMl '.
On comprend, au vu de la description du modèle en cloud Computing fournie en relation avec la figure 1 que le microprocesseur 103, les mémoires 104, 105, les interfaces de communication 106 sont des ressources matérielles qui appartiennent à la couche d'exécution matérielles 10-1. Ces ressources sont destinées à être virtualisées par l'hyperviseur 101 et mises à disposition des machines virtuelles VMl, VMl ' et de l'agent 102 d'aide à l'identification d'incidents 102 sous forme virtualisées. C'est en effet, l'hyperviseur 101 qui alloue la zone mémoire à l'agent 102.
Le dispositif d'aide à l'identification d'incidents 10 comprend également :
- des moyens de réception 107, agencés pour recevoir en provenance du système d'exploitation de la machine virtuelle VMl au moins une instruction machine correspondant à une interruption au niveau du système d'exploitation OS1 de la machine virtuelle VMl, ladite interruption étant consécutive à un événement survenu au niveau de la machine virtuelle VMl. Les moyens de réception 107 sont agencés pour mettre en œuvre l'étape E3 du procédé d'aide à l'identification d'incidents décrit précédemment ;
- des moyens 108 d'exécution de l'interruption, agencés pour exécuter l'interruption au moyen des ressources matérielles du système hôte et obtenir un flux de données. Les moyens d'exécution sont agencés pour mettre en œuvre l'étape E4 du procédé d'aide à l'identification d'incidents décrit précédemment ;
- des moyens 109 de duplication et de transmission, agencés pour dupliquer le flux de données obtenu par les moyens 108 d'exécution en un second flux, ou flux dupliqué, pour transmettre le flux au système d'exploitation OS1 de la machine virtuelle VMl et pour mémoriser le flux dupliqué. Les moyens 109 de duplication et de transmission sont agencés pour mettre en œuvre l'étape E5 du procédé décrit précédemment ;
- des moyens 110 de transmission du flux dupliqué, agencés pour transmettre le flux dupliqué au système d'exploitation OS1 ' d'une deuxième machine virtuelle VMl' hébergée par le dispositif 10, avec un décalage delta par rapport à la transmission du flux au système d'exploitation OS1 de la machine virtuelle VMl, la deuxième machine virtuelle VMl ' étant distincte de la machine virtuelle, un incident survenant sur la machine virtuelle ne survenant sur la deuxième machine qu'au moins avec le décalage delta. Les moyens de transmission de flux 110 sont agencés pour mettre en œuvre l'étape E6 du procédé d'aide à l'identification d'incidents décrit précédemment.
Dans un exemple de réalisation, le dispositif d'aide à la décision d'incidents 10 comprend également : - des moyens 111 de détection et de mise en pause (en pointillés sur la figure 3), agencés pour détecter un incident sur la machine virtuelle VM1, et pour mettre en pause l'exécution de la deuxième machine virtuelle VM1 ',
- des moyens 112 de transmission et d'observation (en pointillés sur la figure 3), agencés pour transmettre pas à pas des flux de données à la machine virtuelle dupliquée VM1 ', et pour observer à chaque pas et à partir de journaux d'exécution l'impact d'un desdits flux transmis sur la machine virtuelle dupliquée.
Les interfaces de communication 106, les moyens de réception 107, les moyens 108 d'exécution de l'interruption, les moyens 109 de duplication et de transmission, les moyens 110 de traitement du flux dupliqué, les moyens 111 de détection et de mise en pause, les moyens
112 de transmission et d'observation, l'agent de sécurité 102, l'hyperviseur 101 sont de préférence des modules logiciels comprenant des instructions logicielles pour faire exécuter les étapes du procédé d'aide à l'identification d'incidents précédemment décrit.
L'invention concerne donc aussi :
- un programme d'ordinateur comportant des instructions pour la mise en œuvre du procédé de supervision de la sécurité tel que décrit précédemment lorsque ce programme est exécuté par un processeur du dispositif de supervision 10,
- un support d'enregistrement lisible sur lequel est enregistré le programme d'ordinateur décrit ci-dessus.
Les modules logiciels peuvent être stockés dans, ou transmis par un support de données.
Celui-ci peut être un support matériel de stockage, par exemple un CD-ROM, une disquette magnétique ou un disque dur, ou bien un support de transmission tel qu'un signal ou un réseau de télécommunication.

Claims

REVENDICATIONS
1. Procédé d'aide à l'identification d'incidents sur une machine virtuelle (VM1) hébergée par un système hôte (10), la machine virtuelle comprenant un système d'exploitation (OS1) communiquant avec un hyperviseur (101) du système hôte, ledit hyperviseur s'interfaçant entre le système d'exploitation et des ressources matérielles du système hôte, ledit procédé comprenant les étapes suivantes, mises en œuvre par l'hyperviseur :
- réception (E3), en provenance du système d'exploitation, d'au moins une instruction machine correspondant à une interruption au niveau du système d'exploitation, ladite interruption étant consécutive à un événement survenu au niveau de la machine virtuelle,
- exécution (E4) de l'instruction par l'hyperviseur au moyen des ressources matérielles du système hôte et transmission (E5) au système d'exploitation d'un flux de données comprenant le résultat de l'exécution de l'interruption,
caractérisé en ce que le flux de données est dupliqué (E5) en un second flux, ledit second flux étant transmis au système d'exploitation d'une deuxième machine virtuelle (VM1 ') avec un décalage par rapport à la transmission du flux au système d'exploitation de la machine virtuelle, la deuxième machine virtuelle étant distincte de la machine virtuelle, un incident survenant sur la machine virtuelle ne survenant sur la deuxième machine qu'au moins avec le décalage.
2. Procédé selon l'une des revendications précédentes comprenant en outre les étapes de :
- détection (E7) d'un incident sur la machine virtuelle (VM1) et mise en pause de l'exécution de la deuxième machine virtuelle (VM1 '),
- transmission (E8) pas à pas des flux de données à la machine virtuelle dupliquée, e et observation à chaque pas et à partir de journaux d'exécution de l'impact d'un desdits flux transmis sur la machine virtuelle dupliquée.
3. Procédé selon la revendication 1 ou la revendication 2, dans lequel le décalage est exprimé par un intervalle de temps.
4. Procédé selon la revendication 2, dans lequel l'intervalle de temps est inférieur ou égal à 20 secondes.
5. Procédé salon la revendication 1 ou la revendication 2, dans lequel le décalage est exprimé par un nombre de flux de données, un flux de données comprenant le résultat de l'exécution d'une interruption par le système d'exploitation de la machine virtuelle.
6. Procédé selon la revendication 5, dans lequel le nombre de flux de données est inférieur ou égal à 10000.
7 Procédé selon l'une des revendications 2 à 6, dans lequel un pas d'observation comprend au moins deux flux de données.
8. Serveur (10) mettant en œuvre une entité d'aide à l'identification d'incidents survenant sur une machine virtuelle (VM1) hébergée par le serveur (10), ladite entité résidant dans une couche virtuelle du serveur, ladite machine virtuelle comprenant un système d'exploitation (OS1) communiquant avec un hyperviseur du serveur, ledit hyperviseur s'interfaçant entre le système d'exploitation et des ressources matérielles du serveur, ledit serveur comprenant :
- des moyens de réception (107), agencés pour recevoir en provenance du système d'exploitation, au moins une instruction machine correspondant à une interruption au niveau du système d'exploitation, ladite interruption étant consécutive à un événement survenu au niveau de la machine virtuelle,
- des moyens (108) d'exécution, agencés pour exécuter l'instruction au moyen des ressources matérielles du système hôte
- des moyens (109) de duplication et de transmission , agencés pour dupliquer le flux de données en un second flux, et pour transmettre au système d'exploitation d'un flux de données comprenant le résultat de l'exécution de l'interruption,
- des moyens (110) de transmission de flux, agencés pour transmettre le second flux au système d'exploitation d'une deuxième machine virtuelle (VM1 ') hébergée par le serveur, avec un décalage par rapport à la transmission du flux au système d'exploitation de la machine virtuelle, la deuxième machine virtuelle étant distincte de la machine virtuelle, un incident survenant sur la machine virtuelle ne survenant sur la deuxième machine qu'au moins avec le décalage.
9. Programme d'ordinateur sur un support de données et chargeable dans la mémoire d'un ordinateur, le programme comprenant des instructions de code pour l'exécution des étapes du procédé d'aide à l'identification d'incidents sur une machine virtuelle selon l'une des revendications 1 à 6, lorsque le programme est exécuté sur ledit ordinateur
10. Support de données dans lequel est enregistré le programme selon la revendication 9.
PCT/FR2016/050712 2015-03-31 2016-03-30 Procede d'aide a l'identification d'incidents dans une architecture d'informatique dans le nuage WO2016156736A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1552759 2015-03-31
FR1552759A FR3034541A1 (fr) 2015-03-31 2015-03-31 Procede d'aide a l'identification d'incidents dans une architecture d'informatique dans le nuage

Publications (1)

Publication Number Publication Date
WO2016156736A1 true WO2016156736A1 (fr) 2016-10-06

Family

ID=53794314

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2016/050712 WO2016156736A1 (fr) 2015-03-31 2016-03-30 Procede d'aide a l'identification d'incidents dans une architecture d'informatique dans le nuage

Country Status (2)

Country Link
FR (1) FR3034541A1 (fr)
WO (1) WO2016156736A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080222729A1 (en) * 2007-03-05 2008-09-11 Songqing Chen Containment of Unknown and Polymorphic Fast Spreading Worms
US8201026B1 (en) * 2010-08-31 2012-06-12 Google Inc. Fault-resistant just-in-time compiler

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080222729A1 (en) * 2007-03-05 2008-09-11 Songqing Chen Containment of Unknown and Polymorphic Fast Spreading Worms
US8201026B1 (en) * 2010-08-31 2012-06-12 Google Inc. Fault-resistant just-in-time compiler

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
CHEN P M ET AL: "When virtual is better than real", HOT TOPICS IN OPERATING SYSTEMS, 2001. PROCEEDINGS OF THE EIGHTH WORKSHOP ON 20-22 MAY 2001, IEEE, PISCATAWAY, NJ, USA, 20 May 2001 (2001-05-20), pages 133 - 138, XP010583095, ISBN: 978-0-7695-1040-8, DOI: 10.1109/HOTOS.2001.990073 *

Also Published As

Publication number Publication date
FR3034541A1 (fr) 2016-10-07

Similar Documents

Publication Publication Date Title
US11743116B2 (en) Methods and apparatus to scale application deployments in cloud computing environments
US11307939B2 (en) Low impact snapshot database protection in a micro-service environment
JP6728409B2 (ja) 仮想化マネージャのセキュアなブート処理
US10509665B2 (en) Fast-booting application image
Machida et al. Modeling and analysis of software rejuvenation in a server virtualized system with live VM migration
FR3022371A1 (fr) Procede de supervision de la securite d'une machine virtuelle dans une architecture d'informatique dans le nuage
TWI544328B (zh) 用於經由背景虛擬機器的探測插入的方法及系統
US9858157B2 (en) Intelligent restore-container service offering for backup validation testing and business resiliency
US20190332368A1 (en) Per request computer system instances
JP2019525306A (ja) 部分的にオフロードされた仮想化マネージャにおけるメモリ割当て技術
US20200034182A1 (en) Supporting quality-of-service for virtual machines based on operational events
JP2019525312A (ja) オポチュニスティックハイパーバイザを用いたパフォーマンスの変動の低減
US11115348B2 (en) Virtual resource allocation for processing an event queue
FR2882448A1 (fr) Procede de gestion, de journalisation ou de rejeu du deroulement d'un processus applicatif
FR2882449A1 (fr) Procede non intrusif de rejeu d'evenements internes au sein d'un processus applicatif, et systeme mettant en oeuvre ce procede
EP2962242A1 (fr) Procede de detection d'attaques de machines virtuelles
US20150193226A1 (en) Instrumentation agent for manipulating component responses
US11550697B2 (en) Cross jobs failure dependency in CI/CD systems
WO2016156736A1 (fr) Procede d'aide a l'identification d'incidents dans une architecture d'informatique dans le nuage
US11656930B2 (en) Minimizing impact of first failure data capture on computing system using recovery process boost
US11327824B2 (en) Using a web server to obtain service data for a failed software application
Bouizem Fault tolerance in FaaS environments
US11886283B2 (en) Automatic node crash detection and remediation in distributed computing systems
EP3502949A1 (fr) Procédé et système de contrôle d'ordonnancement de tâches logicielles
US11656933B2 (en) System tuning across live partition migration

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16721860

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16721860

Country of ref document: EP

Kind code of ref document: A1