FR3034541A1 - 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
FR3034541A1
FR3034541A1 FR1552759A FR1552759A FR3034541A1 FR 3034541 A1 FR3034541 A1 FR 3034541A1 FR 1552759 A FR1552759 A FR 1552759A FR 1552759 A FR1552759 A FR 1552759A FR 3034541 A1 FR3034541 A1 FR 3034541A1
Authority
FR
France
Prior art keywords
virtual machine
operating system
stream
machine
hypervisor
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.)
Pending
Application number
FR1552759A
Other languages
English (en)
Inventor
Aurelien Wailly
Aymeric Tabourin
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.)
Orange SA
Original Assignee
Orange SA
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 SA filed Critical Orange SA
Priority to FR1552759A priority Critical patent/FR3034541A1/fr
Priority to PCT/FR2016/050712 priority patent/WO2016156736A1/fr
Publication of FR3034541A1 publication Critical patent/FR3034541A1/fr
Pending legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14Error detection or correction of the data by redundancy in operation
    • G06F11/1497Details of time redundant execution on a single processing unit
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14Error detection or correction of the data by redundancy in operation
    • G06F11/1479Generic software techniques for error detection or fault masking
    • G06F11/1482Generic software techniques for error detection or fault masking by means of middleware or OS functionality
    • G06F11/1484Generic software techniques for error detection or fault masking by means of middleware or OS functionality involving virtual machines
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/362Software debugging
    • G06F11/3636Software debugging by tracing the execution of the program
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • G06F9/45558Hypervisor-specific management and integration aspects
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06Management of faults, events, alarms or notifications
    • H04L41/0631Management 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/0645Management 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/40Arrangements 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
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • G06F9/45558Hypervisor-specific management and integration aspects
    • G06F2009/45591Monitoring or debugging support

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

1 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 3034541 2 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 oeuvre 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 5 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 10 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.
15 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 : 20 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 25 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 30 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 à 35 être transmis en décalé à la deuxième machine virtuelle dès lors qu'un incident est détecté au 3034541 3 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 5 (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 10 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 15 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.
20 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 25 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 à 30 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 35 système d'exploitation de la machine virtuelle.
3034541 4 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.
5 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 à 10 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.
15 L'invention porte également sur un serveur mettant en oeuvre 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 20 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, 25 - 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, 30 - 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.
3034541 5 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 5 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 10 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 oeuvre 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 15 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.
20 Un modèle d'architecture adapté pour la mise en oeuvre 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 25 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 30 d'exécution matérielle 10-1. Cette couche d'exécution matérielle 10-1 comprend un ensemble de ressources matérielles ri, 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 35 virtuelles, par exemple le système d'exploitation 0S1 d'une machine virtuelle VM1, d'une 3034541 6 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 ri, r2, r3, r4, etc. de la couche d'exécution matérielle 10-1. La couche de virtualisation 10-2 est mise en oeuvre par un module de virtualisation appelé habituellement hyperviseur 101 qui gère l'allocation des 5 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 10 associées à cette couche sont les machines virtuelles, par exemple la machine virtuelle VM1, 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 15 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 20 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 25 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 0S1 de la machine virtuelle VM1, 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 30 0S1 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 VM1. 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 VM1. Il est connu que l'exécution de la routine 3034541 7 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 VM1 à l'architecture matérielle sous-jacente. Selon l'exemple de réalisation décrit, la couche de 5 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 VM1 lorsque l'agent 102 est associé à la machine virtuelle VM1 par l'hyperviseur 101. Un incident est un événement qui ne fait pas partie du fonctionnement standard et attendu d'un 10 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 15 d'incidents 102 est un module logiciel autonome comprenant des instructions de code pour mettre en oeuvre 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 VM1. A cette fin, l'hyperviseur 101 est agencé pour dupliquer la machine virtuelle VM1 en une deuxième machine virtuelle VM1' (en pointillés sur 20 la figure 1). La deuxième machine VM1' possède les mêmes caractéristiques que la machine VM1 : 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 VM1. Elle est donc différente de la machine VM1. 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 25 mémoire distincte des pages mémoire allouées aux machines virtuelles VM1 et VM1' 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 VM1. 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 VM1 et pour le mémoriser temporairement, avant de le transmettre à la 30 deuxième machine virtuelle VM1'. Ainsi, la deuxième machine virtuelle VM1' se comporte de la même manière que la machine virtuelle VM1 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 VM1'. 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 35 sur détection d'un incident sur la machine virtuelle VM1. L'agent 102 est également agencé 3034541 8 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 5 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 10 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 15 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.
20 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.
25 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 30 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 3034541 9 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 VM1 est démarrée ou redémarrée par le fournisseur de services. Ce démarrage 5 signifie que la machine virtuelle VM1 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 VM1 sont alors fournies par l'hyperviseur 101 à la machine virtuelle VM1 pour que celle-ci s'exécute. Le client peut alors disposer de sa machine virtuelle VM1 afin d'installer tous les logiciels dont il a besoin pour son activité.
10 Une fois la machine virtuelle VM1 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 VM1 du client. Cette duplication consiste à créer une deuxième machine virtuelle VM1' similaire à la machine virtuelle VM1 du client mais cependant distincte. « Similaire » signifie que la machine dupliquée VM1' possède les mêmes caractéristiques que la machine virtuelle VM1 du client : 15 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 VM1. La machine dupliquée VM1' est donc distincte de la machine virtuelle VM1 mais se comporte de façon similaire à la machine virtuelle VM1 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 20 d'incidents 102 une zone mémoire tampon sur une page mémoire distincte de celles allouées à la machine virtuelle VM1 et à la machine dupliquée VM1'. 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 VM1 et VM1'. Dans une variante de réalisation, la deuxième machine virtuelle VM1' 25 est démarrée en même temps que la machine VM1, au cours de l'étape E0 de démarrage ou de redémarrage, à partir de la configuration de la machine virtuelle VM1. 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 VM1.
30 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 VM1'. Au terme de cette association, l'agent 102 est apte à superviser l'exécution de la machine virtuelle dupliquée VM1' afin de fournir une aide à l'identification d'incidents lorsque ceux-là surviennent sur la machine virtuelle VM1.
3034541 10 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 5 VM1 du client déclenche une interruption au niveau du système d'exploitation 0S1 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 0S1 de la 10 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 15 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 20 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é 25 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 30 virtuelle VM1 à une date TO, le même flux de données dupliqué est transmis par l'agent 102 d'aide à l'identification d'incidents à une date TO + 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 35 l'expiration de délais (on parle de « timeout » en anglais) propres à des programmes de 3034541 11 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 VM1' et de la rendre inopérante. Il est également connu que certaines commandes systèmes tiennent compte du temps de traitement d'une 5 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 VM1 à 10 l'instant TO, le flux dupliqué est transmis à la deuxième machine virtuelle VM1' à un instant suivant T1 tel que pendant la durée T1 - TO, nbF flux, correspondant au traitement de nbF interruptions, ont été transmis à la machine virtuelle VM1. 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 15 de données, correspondant au traitement de la nbF-plus unième interruption, l'agent 102 envoie à la deuxième machine virtuelle VM1' 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 20 que, quel que soit la façon d'exprimer le décalage delta, la machine dupliquée VM1' est impactée de la même façon que la machine virtuelle VM1 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 VM1. On rappelle qu'un incident correspond ici à un événement 25 qui ne fait pas partie du fonctionnement normal et attendu de la machine virtuelle VM1. Par exemple, la machine virtuelle arrête de fonctionner, ou la machine virtuelle VM1 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 30 VM1' ne sont pas transmis à la machine dupliquée VM1' ; ils restent stockés dans la mémoire tampon. Il y a donc une mise en pause de la deuxième machine virtuelle VM1'. 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 à 35 l'identification d'incidents. L'opérateur de sécurité débloque successivement les flux de 3034541 12 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 VM1, à 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 VM1' au niveau des journaux systèmes dont il 5 dispose. Une analyse pas à pas des impacts des flux de données sur la deuxième machine virtuelle VM1' 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 VM1 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 10 l'exécution de la machine virtuelle dupliquée VM1' sont débloqués un à un, c'est-à-dire que l'exécution de la machine virtuelle dupliquée VM1' 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 VM1. 15 « 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 VM1' 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 VM1 et VM1', 20 ni aucune redondance puisqu'elles sont complètement distinctes, c'est-à-dire sur des pages mémoire disjointes. La machine virtuelle VM1 ne subit donc aucun effet de bord du fait de la duplication du flux et du traitement effectué sur la machine virtuelle dupliquée VM1'. 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 25 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 VM1' 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 30 identiques les états de la machine virtuelle VM1 et de la machine dupliquée VM1'. Aucune action ne doit donc être entreprise sur la machine dupliquée VM1' au risque de générer un état différent sur la machine dupliquée VM1'. 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 VM1 du client.
3034541 13 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 5 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 10 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 15 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 20 en oeuvre 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 »), 25 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 30 « 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 oeuvre 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 35 communiquent. En particulier, les interfaces 106 sont adaptées pour faciliter la communication 3034541 14 entre l'agent 102 d'aide à l'identification d'incidents, la machine virtuelle VM1 et son système d'exploitation OS1, et la machine virtuelle dupliquée VM1'. 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 5 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 VM1, VM1' 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.
10 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 VM1 au moins une instruction machine correspondant à une interruption au niveau du système d'exploitation 0S1 de la machine virtuelle VM1, ladite interruption étant consécutive à un événement survenu au niveau de la machine virtuelle VM1.
15 Les moyens de réception 107 sont agencés pour mettre en oeuvre 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 oeuvre l'étape E4 du procédé d'aide à l'identification 20 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 0S1 de la machine virtuelle VM1 et pour mémoriser le flux dupliqué. Les moyens 109 de duplication et de transmission sont agencés 25 pour mettre en oeuvre 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 0S1' d'une deuxième machine virtuelle VM1' hébergée par le dispositif 10, avec un décalage delta par rapport à la transmission du flux au système d'exploitation 0S1 de la machine virtuelle VM1, la deuxième machine virtuelle VM1' étant 30 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 oeuvre 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 35 comprend également : 3034541 15 - 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), 5 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 10 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 : 15 - un programme d'ordinateur comportant des instructions pour la mise en oeuvre 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.
20 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. 25

Claims (10)

  1. REVENDICATIONS1. 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 (0S1) 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 oeuvre 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. 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. 3. Procédé selon la revendication 1 ou la revendication 2, dans lequel le décalage est exprimé par un intervalle de temps.
  4. 4. Procédé selon la revendication 2, dans lequel l'intervalle de temps est inférieur ou égal à 20 secondes. 3034541 17
  5. 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. 5
  6. 6. Procédé selon la revendication 5, dans lequel le nombre de flux de données est inférieur ou égal à 10000.
  7. 7 Procédé selon l'une des revendications 2 à 6, dans lequel un pas d'observation comprend au moins deux flux de données. 10
  8. 8. Serveur (10) mettant en oeuvre 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 (0S1) communiquant avec un hyperviseur du serveur, ledit hyperviseur 1 5 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 20 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 25 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 30 survenant sur la machine virtuelle ne survenant sur la deuxième machine qu'au moins avec le décalage.
  9. 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 3034541 18 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. 10. Support de données dans lequel est enregistré le programme selon la revendication 5 9.
FR1552759A 2015-03-31 2015-03-31 Procede d'aide a l'identification d'incidents dans une architecture d'informatique dans le nuage Pending FR3034541A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
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
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

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
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
FR3034541A1 true FR3034541A1 (fr) 2016-10-07

Family

ID=53794314

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1552759A Pending FR3034541A1 (fr) 2015-03-31 2015-03-31 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
WO2016156736A1 (fr) 2016-10-06

Similar Documents

Publication Publication Date Title
US10678656B2 (en) Intelligent restore-container service offering for backup validation testing and business resiliency
US11307939B2 (en) Low impact snapshot database protection in a micro-service environment
US20210111957A1 (en) Methods, systems and apparatus to propagate node configuration changes to services in a distributed environment
US10509665B2 (en) Fast-booting application image
TWI544328B (zh) 用於經由背景虛擬機器的探測插入的方法及系統
EP3155551A1 (fr) Procédé de supervision de la sécurité d'une machine virtuelle dans une architecture d'informatique dans le nuage
US10346148B2 (en) Per request computer system instances
JP2019525306A (ja) 部分的にオフロードされた仮想化マネージャにおけるメモリ割当て技術
FR2881246A1 (fr) Procede perdictif de gestion, de journalisation ou de rejeu d'operations non deterministes au sein du deroulement d'un processus applicatif
JP2019525312A (ja) オポチュニスティックハイパーバイザを用いたパフォーマンスの変動の低減
FR2882448A1 (fr) Procede de gestion, de journalisation ou de rejeu du deroulement d'un processus applicatif
US20170359243A1 (en) Compute node cluster management
US20210294896A1 (en) Endpoint detection and response attack process tree auto-play
US10284660B1 (en) Data flow tokens to trace execution of services in a service provider network
US11115348B2 (en) Virtual resource allocation for processing an event queue
US11113244B1 (en) Integrated data pipeline
FR2882449A1 (fr) Procede non intrusif de rejeu d'evenements internes au sein d'un processus applicatif, et systeme mettant en oeuvre ce procede
WO2014132009A1 (fr) Procede de detection d'attaques de machines virtuelles
US9596157B2 (en) Server restart management via stability time
US20150193226A1 (en) Instrumentation agent for manipulating component responses
WO2016156736A1 (fr) Procede d'aide a l'identification d'incidents dans une architecture d'informatique dans le nuage
US20160062777A1 (en) Managing middleware using an application manager
US20220405163A1 (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

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20161007