CA2493407C - Procede de replication d'une application logicielle dans une architecture multi-ordinateurs, procede pour realiser une continuite de fonctionnement mettant en oeuvre ce procede de replication, et systeme multi-ordinateurs ainsi equipe - Google Patents
Procede de replication d'une application logicielle dans une architecture multi-ordinateurs, procede pour realiser une continuite de fonctionnement mettant en oeuvre ce procede de replication, et systeme multi-ordinateurs ainsi equipe Download PDFInfo
- Publication number
- CA2493407C CA2493407C CA2493407A CA2493407A CA2493407C CA 2493407 C CA2493407 C CA 2493407C CA 2493407 A CA2493407 A CA 2493407A CA 2493407 A CA2493407 A CA 2493407A CA 2493407 C CA2493407 C CA 2493407C
- Authority
- CA
- Canada
- Prior art keywords
- application
- replication
- resources
- node
- cluster
- 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.)
- Expired - Lifetime
Links
- 238000000034 method Methods 0.000 title claims abstract description 113
- 230000010076 replication Effects 0.000 title claims abstract description 69
- 230000003362 replicative effect Effects 0.000 title claims abstract description 5
- 241000711981 Sais Species 0.000 title 1
- 230000007246 mechanism Effects 0.000 claims abstract description 48
- 230000008569 process Effects 0.000 claims description 61
- 230000015654 memory Effects 0.000 claims description 18
- 238000012546 transfer Methods 0.000 claims description 10
- 230000004888 barrier function Effects 0.000 claims description 5
- 238000001514 detection method Methods 0.000 claims description 4
- 238000012423 maintenance Methods 0.000 claims description 4
- 230000006870 function Effects 0.000 claims description 3
- 230000003936 working memory Effects 0.000 claims 1
- XLYOFNOQVPJJNP-UHFFFAOYSA-N water Substances O XLYOFNOQVPJJNP-UHFFFAOYSA-N 0.000 description 6
- 238000005457 optimization Methods 0.000 description 4
- 238000011084 recovery Methods 0.000 description 4
- 230000009471 action Effects 0.000 description 3
- 230000000903 blocking effect Effects 0.000 description 3
- 230000004048 modification Effects 0.000 description 3
- 238000012986 modification Methods 0.000 description 3
- 238000012544 monitoring process Methods 0.000 description 3
- 230000008859 change Effects 0.000 description 2
- 238000010367 cloning Methods 0.000 description 2
- 230000001427 coherent effect Effects 0.000 description 2
- 238000013461 design Methods 0.000 description 2
- 230000008520 organization Effects 0.000 description 2
- 230000000737 periodic effect Effects 0.000 description 2
- 230000004913 activation Effects 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 230000015572 biosynthetic process Effects 0.000 description 1
- 230000015556 catabolic process Effects 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 230000001186 cumulative effect Effects 0.000 description 1
- 230000006378 damage Effects 0.000 description 1
- 238000006731 degradation reaction Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000018109 developmental process Effects 0.000 description 1
- 230000008034 disappearance Effects 0.000 description 1
- 239000000463 material Substances 0.000 description 1
- 230000005012 migration Effects 0.000 description 1
- 238000013508 migration Methods 0.000 description 1
- 238000004321 preservation Methods 0.000 description 1
- 238000012163 sequencing technique Methods 0.000 description 1
- 230000001629 suppression Effects 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 238000003786 synthesis reaction Methods 0.000 description 1
- 238000013519 translation Methods 0.000 description 1
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/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/2097—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements maintaining the standby controller/processing unit updated
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
- G06F11/2038—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant with a single idle spare processing component
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
- G06F11/2041—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant with more than one idle spare processing component
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
- G06F11/2046—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant where the redundant components share persistent storage
Abstract
Procédé pour répliquer une application logicielle dans une architecture multi-ordinateurs (cluster), cette application logicielle étant préalablement exécutée sur un premier ordinateur du cluster constituant un n.oelig.ud primaire ou opérationnel et étant destinée à être répliquée sur au moins un autre ordinateur du cluster constituant un n.oelig.ud secondaire, comprenant une réplication des ressources associées à cette application logicielle. Ce procédé comprend une mise à jour au fil de l'eau des ressources répliquées par un mécanisme d'introspection dynamique prévu pour fournir la structure de l'application à répliquer, ainsi que le graphe dynamique des ressources et dépendances mises en .oelig.uvre.
Description
Procédé de réplication d'une application logicielle dans une architecture multi-ordinateurs, procédé pour réaliser une continuité de fonctionnement mettant en oeuvre ce procédé de réplication, et système multi-ordinateurs ainsi équipé
La présente invention concerne un procédé pour répliquer une application logicielle dans une architecture multi-ordinateurs (cluster). Elle vise également un procédé pour réaliser une continuité de fonctionnement d'une application logicielle au sein d'un cluster d'ordinateurs, qui met en oeuvre le procédé de réplication selon l'invention, ainsi qu'un système multi-ordinateurs implémentant ce procédé de continuité de fonctionnement.
Le domaine de l'invention est celui des- clusters d'ordinateurs formés de plusieurs ordinateurs collaborant entre eux. Ces clusters sont par exemple prévus pour exécuter des applications logicielles. Ainsi, à un instant donné, une application est exécutée sur l'un des ordinateurs du cluster, appelé noeud primaire ou opérationnel (OP), tandis que les.
autres ordinateurs du cluster sont appelés naeuds secondaires ou stand-by (SB), dans un contexte d'architecture redondante.
Or, l'exploitation de tels clusters montre que se posent des problèmes de fiabilité qui peuvent être dus à des défaillances du matériel ou du système d'exploitation, à des erreurs humaines, ou à la défaillance des applications elles-mêmes.
Pour résoudre ces problèmes de fiabilité, il existe actuellement des mécanismes, dits de haute disponibilité, qui sont mis en oeuvre sur la plupart des clusters actuels et qui sont basés sur un redémarrage automatique à froid de
La présente invention concerne un procédé pour répliquer une application logicielle dans une architecture multi-ordinateurs (cluster). Elle vise également un procédé pour réaliser une continuité de fonctionnement d'une application logicielle au sein d'un cluster d'ordinateurs, qui met en oeuvre le procédé de réplication selon l'invention, ainsi qu'un système multi-ordinateurs implémentant ce procédé de continuité de fonctionnement.
Le domaine de l'invention est celui des- clusters d'ordinateurs formés de plusieurs ordinateurs collaborant entre eux. Ces clusters sont par exemple prévus pour exécuter des applications logicielles. Ainsi, à un instant donné, une application est exécutée sur l'un des ordinateurs du cluster, appelé noeud primaire ou opérationnel (OP), tandis que les.
autres ordinateurs du cluster sont appelés naeuds secondaires ou stand-by (SB), dans un contexte d'architecture redondante.
Or, l'exploitation de tels clusters montre que se posent des problèmes de fiabilité qui peuvent être dus à des défaillances du matériel ou du système d'exploitation, à des erreurs humaines, ou à la défaillance des applications elles-mêmes.
Pour résoudre ces problèmes de fiabilité, il existe actuellement des mécanismes, dits de haute disponibilité, qui sont mis en oeuvre sur la plupart des clusters actuels et qui sont basés sur un redémarrage automatique à froid de
- 2 -l'application sur un noeud de secours parmi l'un des nasuds secondaires du cluster.
Or ces mécanismes basés sur un redémarrage automatique ne permettent pas d'assurer une continuité totale du services fourni par l'application en cours d'exécution au moment de(a défaillance.
En particulier, se pose le problème de la réplication d'une application logicielle au sein d'une architecture multi-ordinateurs, cette réplication devant assurer une continuité totale de service.
Un objectif principal de la présente invention est donc de proposer un procédé pour répliquer une application logicielle dans une architecture multi-ordinateurs (cluster), ladite application logicielle étant préalablement exécutée sur un premier ordinateur dudit cluster constituant un noeud primaire et étant destinée à être répliquée sur au moins un autre ordinateur dudit cluster constituant un noeud secondaire, comprenant une réplication des ressources associées à ladite application logicielle.
Cet objectif principal est atteint avec un tel procédé
de réplication caractérisé en ce qu'il comprend une mise à
jour au fil de l'eau des ressources répliquées par un mécanisme d'introspection dynamique prévu pour fournir la structure de l'application à répliquer, ainsi que le graphe dynamique des ressources et dépendances mises en oeuvre.
On peut en outre avantageusement prévoir que ce procédé
de réplication comprenne en outre une création et une maintenance d'un arbre de dépendance, qui fournit à chaque instant des informations sur les ressources qu'il est nécessaire de répliquer.
Il est important de noter que dans le procédé de réplication selon l'invention, le nombre de noeuds secondaires ou stand-by concernés peut être quelconque.
Or ces mécanismes basés sur un redémarrage automatique ne permettent pas d'assurer une continuité totale du services fourni par l'application en cours d'exécution au moment de(a défaillance.
En particulier, se pose le problème de la réplication d'une application logicielle au sein d'une architecture multi-ordinateurs, cette réplication devant assurer une continuité totale de service.
Un objectif principal de la présente invention est donc de proposer un procédé pour répliquer une application logicielle dans une architecture multi-ordinateurs (cluster), ladite application logicielle étant préalablement exécutée sur un premier ordinateur dudit cluster constituant un noeud primaire et étant destinée à être répliquée sur au moins un autre ordinateur dudit cluster constituant un noeud secondaire, comprenant une réplication des ressources associées à ladite application logicielle.
Cet objectif principal est atteint avec un tel procédé
de réplication caractérisé en ce qu'il comprend une mise à
jour au fil de l'eau des ressources répliquées par un mécanisme d'introspection dynamique prévu pour fournir la structure de l'application à répliquer, ainsi que le graphe dynamique des ressources et dépendances mises en oeuvre.
On peut en outre avantageusement prévoir que ce procédé
de réplication comprenne en outre une création et une maintenance d'un arbre de dépendance, qui fournit à chaque instant des informations sur les ressources qu'il est nécessaire de répliquer.
Il est important de noter que dans le procédé de réplication selon l'invention, le nombre de noeuds secondaires ou stand-by concernés peut être quelconque.
- 3 -Dans un mode de réalisation préféré de l'invention, le procédé de réplication selon l'invention comprend en outre un mécanisme dit de point de reprise ( checkpointing ) par lequel les ressources à répliquer sont répliquées sur un ou plusieurs naeuds secondaires.
Le procédé de réplication selon l'invention peut avantageusement comprendre les trois étapes suivantes:
- capture des ressources sur le noeud primaire, - transfert par le réseau vers un ou plusieurs noeuds secondaires, - restauration sur le ou les naeuds secondaires.
Le procédé de réplication selon l'invention peut être avantageusement mis en oeuvre pour une optimisation automatique de ressources informatiques par partage de charge par répartition dynamique de processus. Il peut aussi être utilisé pour une maintenance non interrupt'ive par relocation à la demande de processus au travers d'un réseau de ressources informatiques, ou pour une préservation de contexte applicatif dans des applications mobiles.
Un autre but de la présente invention est de proposer un procédé pour réaliser une continuité de fonctionnement d'une application logicielle dans une architecture multi-ordinateurs (cluster), cette application étant exécutée à un instant donné sur l'un des ordinateurs du cluster, appelé
noeud principal ou opérationnel, les autres ordinateurs dudit cluster étant appelés noeuds secondaires.
Cet autre objectif est atteint avec un procédé pour -réaliser une continuité de fonctionnement d'une application logicielle dans une architecture multi-ordinateurs (cluster), cette application étant exécutée à un instant donné sur l'un des ordinateurs du cluster, appelé noeud principal, les autres ordinateurs dudit cluster étant appelés naeuds secondaires.
Le procédé de réplication selon l'invention peut avantageusement comprendre les trois étapes suivantes:
- capture des ressources sur le noeud primaire, - transfert par le réseau vers un ou plusieurs noeuds secondaires, - restauration sur le ou les naeuds secondaires.
Le procédé de réplication selon l'invention peut être avantageusement mis en oeuvre pour une optimisation automatique de ressources informatiques par partage de charge par répartition dynamique de processus. Il peut aussi être utilisé pour une maintenance non interrupt'ive par relocation à la demande de processus au travers d'un réseau de ressources informatiques, ou pour une préservation de contexte applicatif dans des applications mobiles.
Un autre but de la présente invention est de proposer un procédé pour réaliser une continuité de fonctionnement d'une application logicielle dans une architecture multi-ordinateurs (cluster), cette application étant exécutée à un instant donné sur l'un des ordinateurs du cluster, appelé
noeud principal ou opérationnel, les autres ordinateurs dudit cluster étant appelés noeuds secondaires.
Cet autre objectif est atteint avec un procédé pour -réaliser une continuité de fonctionnement d'une application logicielle dans une architecture multi-ordinateurs (cluster), cette application étant exécutée à un instant donné sur l'un des ordinateurs du cluster, appelé noeud principal, les autres ordinateurs dudit cluster étant appelés naeuds secondaires.
4 PCT/FR2003/002371 Suivant l'invention, le procédé comprend les étapes suivantes - réplication de l'application sur au moins des noeuds secondaires, de façon à réaliser au moins un clone de ladite application, - mise à jour au fil de l'eau dudit ou desdits clones, et - en cas de détection d'une défaillance ou d'un événement affectant ledit noeud principal, basculement de service vers l'un au moins desdits clones.
Ainsi, avec le procédé de réalisation de continuité de fonctionnement selon l'invention, il est désormais possible de disposer de naeuds secondaires pourvus de clones d'application résultant de la réplication de l'application et aptes à relayer sans discontinuité cette application en cas de détection de défaillance ou d'événement affectant le naeud principal.
La réplication mise en aeuvre dans le procédé de réplication selon l'invention est avantageusement de type holistique. On dispose ainsi d'un clonage de l'application au fil de l'eau, avec une mise à jour de ces clones, de façon déterministe et complète.
Ces clones sont dits chauds , c'est-à-dire qu'ils sont la réplique exacte de l'application et de tout son contexte opératoire. Ils sont mis à jour régulièrement (périodiquement ou sur évènements caractéristiques). Ces clones contiennent toutes les ressources et informations requises par l'application pour fournir son service.
Le procédé de réplication selon l'invention permet en outre de superviser l'état de toutes les ressources nécessaires au bon fonctionnement de l'application. Quand la dégradation rédhibitoire de l'une d'entre elles est détectée, le procédé de réplication selon l'invention prévoit une
Ainsi, avec le procédé de réalisation de continuité de fonctionnement selon l'invention, il est désormais possible de disposer de naeuds secondaires pourvus de clones d'application résultant de la réplication de l'application et aptes à relayer sans discontinuité cette application en cas de détection de défaillance ou d'événement affectant le naeud principal.
La réplication mise en aeuvre dans le procédé de réplication selon l'invention est avantageusement de type holistique. On dispose ainsi d'un clonage de l'application au fil de l'eau, avec une mise à jour de ces clones, de façon déterministe et complète.
Ces clones sont dits chauds , c'est-à-dire qu'ils sont la réplique exacte de l'application et de tout son contexte opératoire. Ils sont mis à jour régulièrement (périodiquement ou sur évènements caractéristiques). Ces clones contiennent toutes les ressources et informations requises par l'application pour fournir son service.
Le procédé de réplication selon l'invention permet en outre de superviser l'état de toutes les ressources nécessaires au bon fonctionnement de l'application. Quand la dégradation rédhibitoire de l'une d'entre elles est détectée, le procédé de réplication selon l'invention prévoit une
- 5 -élection d'un clone comme nouveau primaire et lui ordonne de prendre la main.
Cette élection est appelée basculement et est transparente pour le reste du monde qui communique avec l'application : bien que le noeud primaire soit mis hors service, le service fourni par l'application n'est pas interrompu car il est repris avec tout son contexte par le clone élu.
On peut ainsi garantir que tout message transmis par le reste du monde à l'application sera traité, soit par le noeud primaire (pré-basculement), soit par le clone (post-basculement). Pour ce faire, le procédé de réplication selon l'invention peut en outre comporter un enregistrement sur chaque clone (en plus du mécanisme de clonage périodique) de tous les messages reçus par le primaire depuis la dernière mis à jour des clones. Ces messages seront réinjectés dans le clone élu nouveau primaire en cas de basculement.
La réplication holistique reprend des mécanismes déjà
mis en oeuvre dans des systèmes existants de migration de process. Cependant, la conception et l'utilisation qui en sont faites dans le procédé de réplication selon l'invention diffèrent de tous les travaux antérieurs connus.
Le procédé de réalisation de continuité de fonctionnement selon l'invention met ainsi en oeuvre une réplication transparente, holistique et optimisée, dédiée à
la continuité de service par délocalisation de l'application et virtualisation des ressources.
Avec ce procédé, on résout plusieurs limitations des implémentations classiques qui les rendaient inopérantes pour une utilisation en tolérance aux pannes au sein d'une architecture multi-ordinateurs en cluster.
Une première limitation résidait dans le problème de l'indépendance entre noeud primaire et noeud secondaire. Dans
Cette élection est appelée basculement et est transparente pour le reste du monde qui communique avec l'application : bien que le noeud primaire soit mis hors service, le service fourni par l'application n'est pas interrompu car il est repris avec tout son contexte par le clone élu.
On peut ainsi garantir que tout message transmis par le reste du monde à l'application sera traité, soit par le noeud primaire (pré-basculement), soit par le clone (post-basculement). Pour ce faire, le procédé de réplication selon l'invention peut en outre comporter un enregistrement sur chaque clone (en plus du mécanisme de clonage périodique) de tous les messages reçus par le primaire depuis la dernière mis à jour des clones. Ces messages seront réinjectés dans le clone élu nouveau primaire en cas de basculement.
La réplication holistique reprend des mécanismes déjà
mis en oeuvre dans des systèmes existants de migration de process. Cependant, la conception et l'utilisation qui en sont faites dans le procédé de réplication selon l'invention diffèrent de tous les travaux antérieurs connus.
Le procédé de réalisation de continuité de fonctionnement selon l'invention met ainsi en oeuvre une réplication transparente, holistique et optimisée, dédiée à
la continuité de service par délocalisation de l'application et virtualisation des ressources.
Avec ce procédé, on résout plusieurs limitations des implémentations classiques qui les rendaient inopérantes pour une utilisation en tolérance aux pannes au sein d'une architecture multi-ordinateurs en cluster.
Une première limitation résidait dans le problème de l'indépendance entre noeud primaire et noeud secondaire. Dans
- 6 -les systèmes clas'siques, la réplication d'une ressource d'un noeud primaire vers un noeud secondaire présuppose et nécessite la présence opérationnelle du naeud primaire pendant tout le procédé. Le procédé de réplication selon l'invention résout cette limitation, puisque le clone peut à tout instant vivre de façon autonome même en cas de disparition du primaire.
Cette dé-corrélation primaire / secondaire est un pré requis pour la tolérance aux pannes.
Comme la réplication implémentée dans le procédé de réplication selon l'invention est holistique, on capture l'intégralité cohérente de ressources asynchrones interdépendantes. Dans les procédés de l'art antérieur, seuls étaient capturés les états de ressources indépendantes.
Une autre limitation des procédés de l'art antérieur résidait dans le problème de l'intrusivité. Le procédé de réplication selon l'invention est non intrusif sur le code source : les instances antérieures nécessitent de modifier le code source (ou de le concevoir explicitement) pour que les processus informatiques créés et les ressources utilisées puissent être migrés.
Il est à noter que pour la mise en oeuvre du procédé de réplication selon l'invention, on peut avantageusement utiliser des techniques d'ingénierie logicielle non intrusive dynamique, qui ont fait l'objet d'une demande de brevet publiée le 2 août 2002 sous le numéro FR2820221. Ces techniques d'ingénierie logicielle permettent de manipuler des applications dans leur représentation binaire (exécutable), de façon à rendre le procédé de réalisation de continuité de fonctionnement selon l'invention transparent pour l'application et donc générique.
Suivant un autre aspect de l'invention, il est proposé un système multi-ordinateurs prévu pour exécuter sur au moins des ordinateurs au moins une application logicielle,
Cette dé-corrélation primaire / secondaire est un pré requis pour la tolérance aux pannes.
Comme la réplication implémentée dans le procédé de réplication selon l'invention est holistique, on capture l'intégralité cohérente de ressources asynchrones interdépendantes. Dans les procédés de l'art antérieur, seuls étaient capturés les états de ressources indépendantes.
Une autre limitation des procédés de l'art antérieur résidait dans le problème de l'intrusivité. Le procédé de réplication selon l'invention est non intrusif sur le code source : les instances antérieures nécessitent de modifier le code source (ou de le concevoir explicitement) pour que les processus informatiques créés et les ressources utilisées puissent être migrés.
Il est à noter que pour la mise en oeuvre du procédé de réplication selon l'invention, on peut avantageusement utiliser des techniques d'ingénierie logicielle non intrusive dynamique, qui ont fait l'objet d'une demande de brevet publiée le 2 août 2002 sous le numéro FR2820221. Ces techniques d'ingénierie logicielle permettent de manipuler des applications dans leur représentation binaire (exécutable), de façon à rendre le procédé de réalisation de continuité de fonctionnement selon l'invention transparent pour l'application et donc générique.
Suivant un autre aspect de l'invention, il est proposé un système multi-ordinateurs prévu pour exécuter sur au moins des ordinateurs au moins une application logicielle,
- 7 -implémentant le procédé pour réaliser une continuité de fonctionnement selon l'invention.
D'autres avantages et caractéristiques de l'invention apparaîtront à l'examen de la description détaillée d'un mode de mise en aeuvre nullement limitatif, et des dessins annexés sur lesquels :
-la figure 1 illustre la fonction de miroir dynamique mise en oeuvre dans le procédé de réplication selon l'invention ;
-la figure 2 illustre schématiquement les principes de réplication de données mis en oeuvre dans le procédé de réplication selon l'invention ;
-la figure 3 représente un exemple d'architecture logicielle mettant en oeuvre le procédé de réplication selon l'invention, pour la supervision et la détection de défaillance ;
-la figure 4 illustre schématiquement des principes de supervision mis en oeuvre dans le procédé de réplication selon l'invention ;
-la figure 5 illustre schématiquement le mécanisme de copie sur écriture ( copy on write ) mis en oeuvre dans ~~= le procédé de réplication selon l'invention ;
-la figure 6 illustre schématiquement le mécanisme d'incrémentation pour réplication mis en oeuvre dans le procédé de réplication selon l'invention ; et -la figure 7 illustre schématiquement le mécanisme de commutation mis en aeuvre dans le procédé de réplication selon l'invention.
On va d'abord décrire, en référence aux figures précitées, le fonctionnement du mécanisme de réplication holistique mis en oeuvre dans le procédé de réplication selon l'invention.
D'autres avantages et caractéristiques de l'invention apparaîtront à l'examen de la description détaillée d'un mode de mise en aeuvre nullement limitatif, et des dessins annexés sur lesquels :
-la figure 1 illustre la fonction de miroir dynamique mise en oeuvre dans le procédé de réplication selon l'invention ;
-la figure 2 illustre schématiquement les principes de réplication de données mis en oeuvre dans le procédé de réplication selon l'invention ;
-la figure 3 représente un exemple d'architecture logicielle mettant en oeuvre le procédé de réplication selon l'invention, pour la supervision et la détection de défaillance ;
-la figure 4 illustre schématiquement des principes de supervision mis en oeuvre dans le procédé de réplication selon l'invention ;
-la figure 5 illustre schématiquement le mécanisme de copie sur écriture ( copy on write ) mis en oeuvre dans ~~= le procédé de réplication selon l'invention ;
-la figure 6 illustre schématiquement le mécanisme d'incrémentation pour réplication mis en oeuvre dans le procédé de réplication selon l'invention ; et -la figure 7 illustre schématiquement le mécanisme de commutation mis en aeuvre dans le procédé de réplication selon l'invention.
On va d'abord décrire, en référence aux figures précitées, le fonctionnement du mécanisme de réplication holistique mis en oeuvre dans le procédé de réplication selon l'invention.
8 _ PCT/FR2003/002371 Pour que l'application puisse correctement tourner sur un noeud secondaire dans le cas d'un basculement, il est nécessaire que l'ensemble des ressources requises par cette application soit également répliqué sur le noeud secondaire.
Si ces ressources sont des ressources à état, i.e.
qu'elles varient au fil de l'exécution de l'application et contribuent à son contexte global, alors leur état doit également être capturé et répliqué de façon cohérente.
L'ensemble de ces ressources est découvert à
l'initialisation de l'application puis maintenu à jour au fil de l'eau par des mécanismes d'introspection dynamique qui permettent d'obtenir automatiquement la structure de l'application à protéger, ainsi que le graphe dynamique des ressources et dépendances mises en oeuvre.
Ces mécanismes s'appuient sur les caractéristiques réflexives des binaires, sur les mécanismes d'héritage des systèmes d'exploitation et sur la surveillance, via une instrumentation binaire, des mécanismes - incluant les appels système - qui contribuent à modifier l'état de ses ressources.
En référence à la figure 4, dans un exemple de mise en oeuvre du procédé de réplication selon l'invention, des pilotes (drivers) d'introspection et de surveillance assurent une surveillance sur tous les naeuds du cluster et transmettrent des données de surveillances à la base d'information de gestion MIB du système. Cette base MIB est sollicitée à la fois dans la gestion du cluster sur le naeud opérationnel pour les déclenchements de point de reprise (checkpoint) et dans la gestion du cluster sur des noeuds back-up . La base MIB est également sollicitée par le gestionnaire de supervision avec une base MIB synthétique et est accédée par l'administrateur système auquel sont associées des interfaces utilisateur graphiques (GUI).
---------- - - ----
Si ces ressources sont des ressources à état, i.e.
qu'elles varient au fil de l'exécution de l'application et contribuent à son contexte global, alors leur état doit également être capturé et répliqué de façon cohérente.
L'ensemble de ces ressources est découvert à
l'initialisation de l'application puis maintenu à jour au fil de l'eau par des mécanismes d'introspection dynamique qui permettent d'obtenir automatiquement la structure de l'application à protéger, ainsi que le graphe dynamique des ressources et dépendances mises en oeuvre.
Ces mécanismes s'appuient sur les caractéristiques réflexives des binaires, sur les mécanismes d'héritage des systèmes d'exploitation et sur la surveillance, via une instrumentation binaire, des mécanismes - incluant les appels système - qui contribuent à modifier l'état de ses ressources.
En référence à la figure 4, dans un exemple de mise en oeuvre du procédé de réplication selon l'invention, des pilotes (drivers) d'introspection et de surveillance assurent une surveillance sur tous les naeuds du cluster et transmettrent des données de surveillances à la base d'information de gestion MIB du système. Cette base MIB est sollicitée à la fois dans la gestion du cluster sur le naeud opérationnel pour les déclenchements de point de reprise (checkpoint) et dans la gestion du cluster sur des noeuds back-up . La base MIB est également sollicitée par le gestionnaire de supervision avec une base MIB synthétique et est accédée par l'administrateur système auquel sont associées des interfaces utilisateur graphiques (GUI).
---------- - - ----
- 9 -Le résultat de ce travail de découverte et d'introspection au fil de l'eau est la création et la maintenance d'un arbre de dépendance , qui fournit au procédé de réplication selon l'invention à chaque instant des informations sur les ressources qu'il est nécessaire de répliquer. L'existence de ce graphe garantit la complétude et la cohérence des clones.
Un autre mécanisme de point de reprise ( checkpointing ), mis en oeuvre dans le procédé de réalisation de continuité de fonctionnement selon l'invention, consiste à répliquer les ressources sur un ou plusieurs naeuds secondaires. Ce mécanisme de réplication des ressources est réalisé en trois étapes :
- capture des ressources sur le noeud primaire, - transfert par le réseau vers un ou plusieurs naeuds secondaires, et - restauration sur le ou les noeuds secondaires.
Les ressources répliquées incluent :
- la mémoire virtuelle de chaque processus concerné
ainsi que sa pile d'appel, - des ressources systèmes (inter process communication, connexion réseau, etc.), et ;t=:
- des données écrites sur disques.
Le mécanisme de réplication des ressources assure que l'ensemble des ressources nécessaires à l'application est transféré de façon complète et cohérente (d'où holistique).
La mise en aeuvre du procédé de réplication selon l'invention garantit que l'application puisse continuer de vivre sur le secondaire sans perdre son contexte :
l'application est délocalisée, le matériel et le système d'exploitation sous-jacent sont virtualisés, l'application se comportant indépendamment de sa localisation physique.
Un autre mécanisme de point de reprise ( checkpointing ), mis en oeuvre dans le procédé de réalisation de continuité de fonctionnement selon l'invention, consiste à répliquer les ressources sur un ou plusieurs naeuds secondaires. Ce mécanisme de réplication des ressources est réalisé en trois étapes :
- capture des ressources sur le noeud primaire, - transfert par le réseau vers un ou plusieurs naeuds secondaires, et - restauration sur le ou les noeuds secondaires.
Les ressources répliquées incluent :
- la mémoire virtuelle de chaque processus concerné
ainsi que sa pile d'appel, - des ressources systèmes (inter process communication, connexion réseau, etc.), et ;t=:
- des données écrites sur disques.
Le mécanisme de réplication des ressources assure que l'ensemble des ressources nécessaires à l'application est transféré de façon complète et cohérente (d'où holistique).
La mise en aeuvre du procédé de réplication selon l'invention garantit que l'application puisse continuer de vivre sur le secondaire sans perdre son contexte :
l'application est délocalisée, le matériel et le système d'exploitation sous-jacent sont virtualisés, l'application se comportant indépendamment de sa localisation physique.
- 10 -En cas de basculement, l'application, n'est pas considérée comme stoppée : elle continue de tourner dans son contexte, mais sur d'autre ressources matérielles.
Les ressources mises en oeuvre par l'application sont diverses et variées (multi process, système d'exploitation, etc.). Elle vivent de façon asynchrone, sur un environnement non déterministe.
Le procédé de réplication selon l'invention met en aeuvre un algorithme de checkpointing (génération de points de reprise) asynchrone : une barrière de synchronisation est transmise à toutes les ressources et le procédé de réplication selon l'invention garantit que la capture d'état est complète et cohérente.
On va maintenant décrire une technique d'optimisation mise en oeuvre dans le procédé de réplication selon l'invention. La capture déterministe et complète de l'état de toutes les ressources est coûteuse pour les performances du système. Or, un faible impact sur les performances de l'application est un pré requis pour l'acceptabilité par le marché du produit et donc in fine pour son utilité. Plusieurs techniques d'optimisation ont donc été conçues et développées pour minimiser cet impact.
4t= Premièrement, le point de reprise quasi synchrone est une optimisation des mécanismes~ de génération de point de reprise (checkpointing) classiques : il offre la cohérence de capture des algorithmes synchrones, sans pour autant nécessiter l'arrêt total du système pendant la capture que nécessitent les algorithmes asynchrones.
La période du point de reprise est ajustable, de sorte à
optimiser le compromis entre le temps de reprise après basculement (potentiellement d'autant plus long que la période entre deux points de reprise est longue) et la quantité d'information d'état à capturer et à transférer.
WO 2004/015574 _ 11 _ PCT/FR2003/002371 Par ailleurs, le point de reprise est incrémental :
seules les différences d'état entre deux points de reprise sont transmises, comme l'illustre l'exemple fonctionnel de la figure 1. Dans cet exemple, un point de reprise incrémental est effectué à partir de l'application maître pour obtenir l'application réplique et un disque partagé entre les deux noeuds primaire et secondaire est mis en ceuvre.
Ainsi, le premier point de reprise est cher en performance (initialisation des clones) mais les suivants sont d'impact faible.
Le point de reprise est également discriminant l'analyse intelligente du graphe de dépendance permet de limiter au strict nécessaire la quantité d'information à
transmettre.
Enfin, des mécanismes de Copy On Write (copie sur écriture) offerts par le système d'exploitation sont mis en oeuvre pour séparer le temps de capture du temps de transfert, en référence à la figure 5 qui illustre un exemple de mise en aeuvre d'un mécanisme de copie sur écriture dans un procédé de réplication selon l'invention, à la suite du déclenchement d'un point de reprise. Dans cet exemple, le mécanisme de copie sur écriture intervient sur des blocs de données (mémoire ou disque) pour une nouvelle référence, après une requête en écriture issue d'un Utilisateur via un process ou un i-node (naeud d'index). Seuls les blocs de données modifiés sont répliqués, comme l'illustre la figure 6.
On va maintenant décrire un exemple de mise en aeuvre du mécanisme de génération de point de reprise quasi-synchrone au sein du procédé de réalisation de continuité de fonctionnement selon l'invention. Ce mécanisme inclut :
- une barrière de synchronisation de processus ( Process Synchronisation Barrier : PSB), - une gestion de ressources ( Ressource Management RM), - une gestion de ressources système ( System Resources Management : (SRM), et - une gestion de ressources de processus ( Process Resources Management (PRM).
La barrière de synchronisation de processus (PSB) est un mécanisme permettant de synchroniser le blocage des processus composant une application tout en respectant la gestion des entrées/sorties en cours, dans le but de pouvoir prendre à un instant T une "photographie" non floue de l'état du système et de l'application.
La gestion de ressources (RM) est un ensemble d'automates génériques permettant de mettre en oeuvre le séquencement des différentes phases du checkpointing vis à
vis des différentes ressources nécessaires pour répliquer une application d'une machine sur une autre:
La gestion de ressources système (SRM) inclut des mécanismes permettant de gérer les différentes routines de gestion des ressources systèmes utilisées par une application (ensemble de processus) lors des différentes phases du mécanisme de génération de point de reprise.
La gestion de ressources de processus (PRM) inclut des mécanismes permettant de gérer les différentes routines de gestion des ressources utilisées par un processus lors des différentes phases du mécanisme de génération de point de' reprise. Ce code est chargé dynamiquement à l'intérieur des processus applicatifs lors de leur lancement.
Il existe aujourd'hui trois phases principales qui sont elles même découpées en différentes phases nécessaires pour la captures des ressources utilisées par l'application.
La raison d'être de ces différentes sous-phases est de minimiser les temps de blocages applicatif liés à la récupération/restauration des différentes ressources applicatives et système ainsi que de garantir la cohérence des informations sauvegardées.
DUMP:
RM_PRE_DUMP
RM DUMP
RM_POST_DUMP
RM ABORT DUMP
RESTORE:
RM_PRE_RESTORE, RM_RESTORE, RM POST RESTORE, RM ABORT RESTORE, SWITCH:
RM_PRE_SWITCH, RM SWITCH, RM_POST_SWITCH, RM ABORT_SWITCH, On va maintenant décrire une virtualisation des ~ :.
ressources systèmes dans le cadre du procédé de réplication selon l'invention. Certaines ressources systèmes UNIX sont caractérisées par un identifiant unique propre à chaque machine. Ces identifiants sont stockés sous forme de variables par les applications, ce qui leur permet de pouvoir les référencer. Lors de la migration d'une application d'une machine à une autre la mémoire des applications est intégralement transférée, y compris les données relatives aux ressources systèmes. Pour pouvoir garantir l'unicité du référencement des ressources système par une application META-CLUSTER met en oeuvre des mécanismes de virtualisation de ces ressources, permettant de maintenir des identifiants uniques entre les différentes machines composant un CLUSTER.
Ces mécanismes de virtualisation sont aujourd'hui appliqués pour les identifiants de ressources système suivants :
- Processus - PIPE
- FIFO
- IPC System V
- Mémoires partagées - Sémaphores - Message queues - Socket AF UNIX
- Threads Les mécanismes de virtualisation assurent donc l'unicité
du référencement d'une ressource système au sein du cluster ainsi que sa translation vers une ressource système sur chaque machine. Ils sont implémentés sous la forme de modules noyau dynamiques assurant la non-préemptivité de requêtes qui leurs sont faites, sur des systèmes mono et multiprocesseurs, et avec une capacité à instrospecter les différentes routines permettant de manipuler ces identifiants.
A titre d'exemple non limitatif, une routine getpid est instrumentée par META lors de la prise en charge de l'application par META-CLUSTER et son utilisation par l'application retourne un CLUSTER PID qui pourra ensuite être utilisé par l'application sur toute routine prenant un PID
comme paramètres (kill, waitpid, ...).
Le procédé de réplication selon l'invention inclut aussi un module de réplication de fichiers de données applicatives entre le noeud opérationnel et le noeud stand-by, désigné sous le terme de CFOR (Cluster File system Optimized Replication Réplication Optimisée de système de Fichier pour Cluster), en en référence à la figure 2.
Le module CFOR réalise ainsi les fonctions suivantes a) écriture de données b) modification du Log (journal) c) ordre de réplication d) synthèse construite à partir des données e) synthèse de transfert f) mise à jour du système de fichiers (FS) Le fonctionnement de ce module de réplication est le suivant : entre chaque copie (dump), CFOR construit à la volée un journal cumulatif et synthétique des modifications apportées au système de fichiers par les applications contrôlées par le cluster.
Les modifications du système de fichier sont extraites à
la volée par instrumentation dans les processus applicatifs des divers appels systèmes: write(2), mkdir(2), rmdir(2), unlink(2)... Le principe consiste à ne mémoriser que les actions sans les données. Ainsi si une application écrit 2Mo dans un fichier, on ne mémorise que l'action "fichier, écriture, début, . fin", les 2Mo de données ayant été
sauvegardés par l'OS sur le disque, il n'est pas nécessaire de les dupliquer ailleurs.
Les écritures multiples sont synthétisées au fil de l'eau. Si une application effectue les actions suivantes:
1.ouverture du fichier 'toto' 2.écriture de 30000 octets à l'offset 30 dans le fichier toto 3.écriture de 20000 octets à l'offset 20 dans le fichier toto 4.fermeture du fichier 'toto' Le log CFOR résultant sera:
=fichier toto, 20 ? 30030 Au moment de la copie (dump), les données structurelles (metadata) ainsi que le contenu des modifications sont enregistrés dans un fichier séparé.
Ce fichier séparé est transmis sur le naeud stand-by et son exploitation permet de synchroniser l'arborescence de manière à ce qu'elle soit strictement identique à celle du noeud opérationnel au moment du dump.
On va maintenant décrire le mécanisme de synchronisation mis en oeuvre dans le procédé de réplication selon l'invention.
Lors de l'apparition d'une machine SB, il faut synchroniser son système de fichiers (FS) par rapport à celui du noeud opérationnel OP. Cette synchronisation doit se faire sans bloquer le noeud opérationnel OP donc elle se fait sur un système de fichiers en constante évolution. Afin d'éviter le problème des images floues, la synchronisation se fait au travers d'un instantané (snapshot) du système de fichiers (file system) du noeud opérationnel OP. La procédure est décomposée en 2 phases afin de limiter la taille du log de CFOR.
1.Création d'un instantané (snapshot) sur le naeud opérationnel OP
2.1ère synchro avec le noeud SB
3.Destruction de l'instantané (snapshot) sur le noeud opérationnel OP
4.Activation du log de CFOR et création d'un. 2éme instantané (snapshot) sur le noeud opérationnel OP
5.2éme synchronisation avec le noeud SB (elle doit être la plus courte possible).
6.Suppression de l'instantané (snapshot) sur le noeud opérationnel OP, le noeud SB étant prêt à recevoir un première copie (dump) totale.
7.A la prochaine copie (dump), transfert du log de CFOR et mise à jour du système de fichiers FS du noeud SB avec les données de CFOR
8.le cycle normal des copie/restauration (dump/restore) est en place.
La recopie de la mémoire d'un processus se fait en analysant dynamiquement l'organisation mémoire interne du processus et en isolant les différentes zones - texte - données - pile d'exécution L'analyse de la mémoire est effectuée sans intrusion dans le code utilisateur en s'appuyant sur les données fournies par le système d'exploitation (Operating System).
Ces données sont capturées et analysées dans le contexte même du processus et permettent de créer la table des zones mémoires utilisées.
Une fois l'analyse terminée, les agents d'interposition des appels.système d'allocation/libération mémoire assurent % le suivi de l'évolution de la table des zones mémoires.
Lors de la copie (dump), seules les zones mémoire modifiables, c'est à dire accessibles en écriture sont transférées sur le noeud stand-by où elles seront recopiées.
Ainsi le processus sur le noeud stand-by contient les mêmes zones mémoires avec les mêmes données que sur le naeud opérationnel.
La sauvegarde du contenu de la mémoire devant être atomique du point de vue d'un processus, elle doit se faire sans que le processus ne puisse en changer l'état, donc processus bloqué. Afin de ne pas bloquer le processus trop longtemps, on s'appuie sur le mécanisme de Copy On Write du système d'exploitation (primitive (fork) par exemple) pour créer une copie de l'image mémoire du processus et on transfert cette image vers les noeuds stand-by. Une fois le transfert terminé, l'image mémoire maintenue par les mécanismes de Copy On Write est supprimée.
Le procédé de réplication selon l'invention met aussi en oeuvre un mécanisme de copie (dump) incrémentale qui s'appuie sur l'analyse mémoire, mais ajoute en plus un mécanisme de protection des pages en écriture.
Une fois l'analyse des pages effectuée, toutes les pages accessibles en écriture sont protégées, c'est à dire qu'une écriture dans une de ces pages déclenche l'émission d'un signal de violation de protection de pages.
` La protection s'appuie sur les mécanismes fournis par le système d'exploitation tel que l'appel système mprotect .
Lorsque l'application tente de modifier une donnée, la ou les pages contenant cette donnée sont marquées comme modifiées et déprotégées. Le déroulement du code applicatif n'est pas impacté par l'adjonction de ces mécanismes (non intrusivité).
Lors d'une copie (dump) incrémentale, seules les pages modifiées depuis le précédent dump sont transférées. La copie (dump) terminée, toutes les pages modifiées sont re-protégées afin de détecter les prochaines écritures. La copie (dump) incrémentale permet de réduire la taille des données à
transférer vers le stand-by à chaque copie (dump).
La gestion des déclenchements des points de reprise peut être effectuée à partir de la base MIB qui reçoit, du noeud primaire ou opérationnel, des informations sur les états du système et de l'application, des informations sur les événements et call-back sur l'application et des informations délivrées par un analyseur d'état synthétique, comme l'illustre la figure 7. L'organisation du basculement de l' application du noeud primaire vers un noeud secondaire agit par exemple sur un dernier point de reprise EVENT, un dernier point de reprise PERIODIC, un enregistrement (logging) d'entrée, et peut inclure :
- le choix d'un scénario de basculement, - le choix d'un point de reprise, - le déclenchement de la restauration, - le déclenchement (ou non) du re-jeu du Log - la notification du nouveau noeud opérationnel.
Bien sûr, l'invention n'est pas limitée aux exemples qui viennent d'être décrits et de nombreux aménagements peuvent être apportés à ces exemples sans sortir du cadre de l'invention.
Les ressources mises en oeuvre par l'application sont diverses et variées (multi process, système d'exploitation, etc.). Elle vivent de façon asynchrone, sur un environnement non déterministe.
Le procédé de réplication selon l'invention met en aeuvre un algorithme de checkpointing (génération de points de reprise) asynchrone : une barrière de synchronisation est transmise à toutes les ressources et le procédé de réplication selon l'invention garantit que la capture d'état est complète et cohérente.
On va maintenant décrire une technique d'optimisation mise en oeuvre dans le procédé de réplication selon l'invention. La capture déterministe et complète de l'état de toutes les ressources est coûteuse pour les performances du système. Or, un faible impact sur les performances de l'application est un pré requis pour l'acceptabilité par le marché du produit et donc in fine pour son utilité. Plusieurs techniques d'optimisation ont donc été conçues et développées pour minimiser cet impact.
4t= Premièrement, le point de reprise quasi synchrone est une optimisation des mécanismes~ de génération de point de reprise (checkpointing) classiques : il offre la cohérence de capture des algorithmes synchrones, sans pour autant nécessiter l'arrêt total du système pendant la capture que nécessitent les algorithmes asynchrones.
La période du point de reprise est ajustable, de sorte à
optimiser le compromis entre le temps de reprise après basculement (potentiellement d'autant plus long que la période entre deux points de reprise est longue) et la quantité d'information d'état à capturer et à transférer.
WO 2004/015574 _ 11 _ PCT/FR2003/002371 Par ailleurs, le point de reprise est incrémental :
seules les différences d'état entre deux points de reprise sont transmises, comme l'illustre l'exemple fonctionnel de la figure 1. Dans cet exemple, un point de reprise incrémental est effectué à partir de l'application maître pour obtenir l'application réplique et un disque partagé entre les deux noeuds primaire et secondaire est mis en ceuvre.
Ainsi, le premier point de reprise est cher en performance (initialisation des clones) mais les suivants sont d'impact faible.
Le point de reprise est également discriminant l'analyse intelligente du graphe de dépendance permet de limiter au strict nécessaire la quantité d'information à
transmettre.
Enfin, des mécanismes de Copy On Write (copie sur écriture) offerts par le système d'exploitation sont mis en oeuvre pour séparer le temps de capture du temps de transfert, en référence à la figure 5 qui illustre un exemple de mise en aeuvre d'un mécanisme de copie sur écriture dans un procédé de réplication selon l'invention, à la suite du déclenchement d'un point de reprise. Dans cet exemple, le mécanisme de copie sur écriture intervient sur des blocs de données (mémoire ou disque) pour une nouvelle référence, après une requête en écriture issue d'un Utilisateur via un process ou un i-node (naeud d'index). Seuls les blocs de données modifiés sont répliqués, comme l'illustre la figure 6.
On va maintenant décrire un exemple de mise en aeuvre du mécanisme de génération de point de reprise quasi-synchrone au sein du procédé de réalisation de continuité de fonctionnement selon l'invention. Ce mécanisme inclut :
- une barrière de synchronisation de processus ( Process Synchronisation Barrier : PSB), - une gestion de ressources ( Ressource Management RM), - une gestion de ressources système ( System Resources Management : (SRM), et - une gestion de ressources de processus ( Process Resources Management (PRM).
La barrière de synchronisation de processus (PSB) est un mécanisme permettant de synchroniser le blocage des processus composant une application tout en respectant la gestion des entrées/sorties en cours, dans le but de pouvoir prendre à un instant T une "photographie" non floue de l'état du système et de l'application.
La gestion de ressources (RM) est un ensemble d'automates génériques permettant de mettre en oeuvre le séquencement des différentes phases du checkpointing vis à
vis des différentes ressources nécessaires pour répliquer une application d'une machine sur une autre:
La gestion de ressources système (SRM) inclut des mécanismes permettant de gérer les différentes routines de gestion des ressources systèmes utilisées par une application (ensemble de processus) lors des différentes phases du mécanisme de génération de point de reprise.
La gestion de ressources de processus (PRM) inclut des mécanismes permettant de gérer les différentes routines de gestion des ressources utilisées par un processus lors des différentes phases du mécanisme de génération de point de' reprise. Ce code est chargé dynamiquement à l'intérieur des processus applicatifs lors de leur lancement.
Il existe aujourd'hui trois phases principales qui sont elles même découpées en différentes phases nécessaires pour la captures des ressources utilisées par l'application.
La raison d'être de ces différentes sous-phases est de minimiser les temps de blocages applicatif liés à la récupération/restauration des différentes ressources applicatives et système ainsi que de garantir la cohérence des informations sauvegardées.
DUMP:
RM_PRE_DUMP
RM DUMP
RM_POST_DUMP
RM ABORT DUMP
RESTORE:
RM_PRE_RESTORE, RM_RESTORE, RM POST RESTORE, RM ABORT RESTORE, SWITCH:
RM_PRE_SWITCH, RM SWITCH, RM_POST_SWITCH, RM ABORT_SWITCH, On va maintenant décrire une virtualisation des ~ :.
ressources systèmes dans le cadre du procédé de réplication selon l'invention. Certaines ressources systèmes UNIX sont caractérisées par un identifiant unique propre à chaque machine. Ces identifiants sont stockés sous forme de variables par les applications, ce qui leur permet de pouvoir les référencer. Lors de la migration d'une application d'une machine à une autre la mémoire des applications est intégralement transférée, y compris les données relatives aux ressources systèmes. Pour pouvoir garantir l'unicité du référencement des ressources système par une application META-CLUSTER met en oeuvre des mécanismes de virtualisation de ces ressources, permettant de maintenir des identifiants uniques entre les différentes machines composant un CLUSTER.
Ces mécanismes de virtualisation sont aujourd'hui appliqués pour les identifiants de ressources système suivants :
- Processus - PIPE
- FIFO
- IPC System V
- Mémoires partagées - Sémaphores - Message queues - Socket AF UNIX
- Threads Les mécanismes de virtualisation assurent donc l'unicité
du référencement d'une ressource système au sein du cluster ainsi que sa translation vers une ressource système sur chaque machine. Ils sont implémentés sous la forme de modules noyau dynamiques assurant la non-préemptivité de requêtes qui leurs sont faites, sur des systèmes mono et multiprocesseurs, et avec une capacité à instrospecter les différentes routines permettant de manipuler ces identifiants.
A titre d'exemple non limitatif, une routine getpid est instrumentée par META lors de la prise en charge de l'application par META-CLUSTER et son utilisation par l'application retourne un CLUSTER PID qui pourra ensuite être utilisé par l'application sur toute routine prenant un PID
comme paramètres (kill, waitpid, ...).
Le procédé de réplication selon l'invention inclut aussi un module de réplication de fichiers de données applicatives entre le noeud opérationnel et le noeud stand-by, désigné sous le terme de CFOR (Cluster File system Optimized Replication Réplication Optimisée de système de Fichier pour Cluster), en en référence à la figure 2.
Le module CFOR réalise ainsi les fonctions suivantes a) écriture de données b) modification du Log (journal) c) ordre de réplication d) synthèse construite à partir des données e) synthèse de transfert f) mise à jour du système de fichiers (FS) Le fonctionnement de ce module de réplication est le suivant : entre chaque copie (dump), CFOR construit à la volée un journal cumulatif et synthétique des modifications apportées au système de fichiers par les applications contrôlées par le cluster.
Les modifications du système de fichier sont extraites à
la volée par instrumentation dans les processus applicatifs des divers appels systèmes: write(2), mkdir(2), rmdir(2), unlink(2)... Le principe consiste à ne mémoriser que les actions sans les données. Ainsi si une application écrit 2Mo dans un fichier, on ne mémorise que l'action "fichier, écriture, début, . fin", les 2Mo de données ayant été
sauvegardés par l'OS sur le disque, il n'est pas nécessaire de les dupliquer ailleurs.
Les écritures multiples sont synthétisées au fil de l'eau. Si une application effectue les actions suivantes:
1.ouverture du fichier 'toto' 2.écriture de 30000 octets à l'offset 30 dans le fichier toto 3.écriture de 20000 octets à l'offset 20 dans le fichier toto 4.fermeture du fichier 'toto' Le log CFOR résultant sera:
=fichier toto, 20 ? 30030 Au moment de la copie (dump), les données structurelles (metadata) ainsi que le contenu des modifications sont enregistrés dans un fichier séparé.
Ce fichier séparé est transmis sur le naeud stand-by et son exploitation permet de synchroniser l'arborescence de manière à ce qu'elle soit strictement identique à celle du noeud opérationnel au moment du dump.
On va maintenant décrire le mécanisme de synchronisation mis en oeuvre dans le procédé de réplication selon l'invention.
Lors de l'apparition d'une machine SB, il faut synchroniser son système de fichiers (FS) par rapport à celui du noeud opérationnel OP. Cette synchronisation doit se faire sans bloquer le noeud opérationnel OP donc elle se fait sur un système de fichiers en constante évolution. Afin d'éviter le problème des images floues, la synchronisation se fait au travers d'un instantané (snapshot) du système de fichiers (file system) du noeud opérationnel OP. La procédure est décomposée en 2 phases afin de limiter la taille du log de CFOR.
1.Création d'un instantané (snapshot) sur le naeud opérationnel OP
2.1ère synchro avec le noeud SB
3.Destruction de l'instantané (snapshot) sur le noeud opérationnel OP
4.Activation du log de CFOR et création d'un. 2éme instantané (snapshot) sur le noeud opérationnel OP
5.2éme synchronisation avec le noeud SB (elle doit être la plus courte possible).
6.Suppression de l'instantané (snapshot) sur le noeud opérationnel OP, le noeud SB étant prêt à recevoir un première copie (dump) totale.
7.A la prochaine copie (dump), transfert du log de CFOR et mise à jour du système de fichiers FS du noeud SB avec les données de CFOR
8.le cycle normal des copie/restauration (dump/restore) est en place.
La recopie de la mémoire d'un processus se fait en analysant dynamiquement l'organisation mémoire interne du processus et en isolant les différentes zones - texte - données - pile d'exécution L'analyse de la mémoire est effectuée sans intrusion dans le code utilisateur en s'appuyant sur les données fournies par le système d'exploitation (Operating System).
Ces données sont capturées et analysées dans le contexte même du processus et permettent de créer la table des zones mémoires utilisées.
Une fois l'analyse terminée, les agents d'interposition des appels.système d'allocation/libération mémoire assurent % le suivi de l'évolution de la table des zones mémoires.
Lors de la copie (dump), seules les zones mémoire modifiables, c'est à dire accessibles en écriture sont transférées sur le noeud stand-by où elles seront recopiées.
Ainsi le processus sur le noeud stand-by contient les mêmes zones mémoires avec les mêmes données que sur le naeud opérationnel.
La sauvegarde du contenu de la mémoire devant être atomique du point de vue d'un processus, elle doit se faire sans que le processus ne puisse en changer l'état, donc processus bloqué. Afin de ne pas bloquer le processus trop longtemps, on s'appuie sur le mécanisme de Copy On Write du système d'exploitation (primitive (fork) par exemple) pour créer une copie de l'image mémoire du processus et on transfert cette image vers les noeuds stand-by. Une fois le transfert terminé, l'image mémoire maintenue par les mécanismes de Copy On Write est supprimée.
Le procédé de réplication selon l'invention met aussi en oeuvre un mécanisme de copie (dump) incrémentale qui s'appuie sur l'analyse mémoire, mais ajoute en plus un mécanisme de protection des pages en écriture.
Une fois l'analyse des pages effectuée, toutes les pages accessibles en écriture sont protégées, c'est à dire qu'une écriture dans une de ces pages déclenche l'émission d'un signal de violation de protection de pages.
` La protection s'appuie sur les mécanismes fournis par le système d'exploitation tel que l'appel système mprotect .
Lorsque l'application tente de modifier une donnée, la ou les pages contenant cette donnée sont marquées comme modifiées et déprotégées. Le déroulement du code applicatif n'est pas impacté par l'adjonction de ces mécanismes (non intrusivité).
Lors d'une copie (dump) incrémentale, seules les pages modifiées depuis le précédent dump sont transférées. La copie (dump) terminée, toutes les pages modifiées sont re-protégées afin de détecter les prochaines écritures. La copie (dump) incrémentale permet de réduire la taille des données à
transférer vers le stand-by à chaque copie (dump).
La gestion des déclenchements des points de reprise peut être effectuée à partir de la base MIB qui reçoit, du noeud primaire ou opérationnel, des informations sur les états du système et de l'application, des informations sur les événements et call-back sur l'application et des informations délivrées par un analyseur d'état synthétique, comme l'illustre la figure 7. L'organisation du basculement de l' application du noeud primaire vers un noeud secondaire agit par exemple sur un dernier point de reprise EVENT, un dernier point de reprise PERIODIC, un enregistrement (logging) d'entrée, et peut inclure :
- le choix d'un scénario de basculement, - le choix d'un point de reprise, - le déclenchement de la restauration, - le déclenchement (ou non) du re-jeu du Log - la notification du nouveau noeud opérationnel.
Bien sûr, l'invention n'est pas limitée aux exemples qui viennent d'être décrits et de nombreux aménagements peuvent être apportés à ces exemples sans sortir du cadre de l'invention.
Claims (14)
1. Procédé pour répliquer une application logicielle comprenant un ensemble de processus dans une architecture multi-ordinateurs de type cluster, ladite application logicielle étant préalablement exécutée sur un premier ordinateur dudit cluster constituant un noeud primaire et étant destinée à être répliquée sur au moins un autre ordinateur dudit cluster constituant un noeud secondaire, le procédé
comprenant les étapes consistant à:
-découvrir les ressources requises par l'application, ces ressources incluant:
- la mémoire virtuelle de chaque processus concerné ainsi que sa pile d'appel, - des ressources systèmes incluant au moins une structure logicielle incluse dans la mémoire de travail du n ud primaire, et - des données écrites sur disques;
-créer et maintenir un graphe de dépendance contenant des informations sur lesdites ressources découvertes, -répliquer lesdites ressources découvertes du n ud primaire vers certains au moins desdits n uds secondaires à partir du graphe de dépendances de manière à
capturer de manière cohérente et complète au niveau de chaque n ud secondaire l'état des ressources requises par l'application dans le n ud primaire, lesdites étapes de découverte des ressources, de création et de maintien du graphe de dépendance étant mises en oeuvre par un mécanisme d'introspection dynamique opérant dans le contexte de chaque processus, ledit mécanisme d'introspection étant apte à analyser dynamiquement l'organisation de la mémoire interne de chaque processus sans intrusion dans le code utilisateur à partir de données fournies par le système d'exploitation.
comprenant les étapes consistant à:
-découvrir les ressources requises par l'application, ces ressources incluant:
- la mémoire virtuelle de chaque processus concerné ainsi que sa pile d'appel, - des ressources systèmes incluant au moins une structure logicielle incluse dans la mémoire de travail du n ud primaire, et - des données écrites sur disques;
-créer et maintenir un graphe de dépendance contenant des informations sur lesdites ressources découvertes, -répliquer lesdites ressources découvertes du n ud primaire vers certains au moins desdits n uds secondaires à partir du graphe de dépendances de manière à
capturer de manière cohérente et complète au niveau de chaque n ud secondaire l'état des ressources requises par l'application dans le n ud primaire, lesdites étapes de découverte des ressources, de création et de maintien du graphe de dépendance étant mises en oeuvre par un mécanisme d'introspection dynamique opérant dans le contexte de chaque processus, ledit mécanisme d'introspection étant apte à analyser dynamiquement l'organisation de la mémoire interne de chaque processus sans intrusion dans le code utilisateur à partir de données fournies par le système d'exploitation.
2. Procédé de réplication selon la revendication 1, caractérisé en ce que l'étape de réplication met en uvre un mécanisme de génération de point de reprise (checkpointing), par lequel les ressources à répliquer sont répliquées sur un ou plusieurs noeuds secondaires.
3. Procédé de réplication selon la revendication 2, caractérisé en ce que le mécanisme de génération de point de reprise comprend trois étapes:
- capture des ressources sélectionnées sur le noeud primaire, - transfert par le réseau vers un ou plusieurs n uds secondaires, et - restauration sur le ou les noeuds secondaires.
- capture des ressources sélectionnées sur le noeud primaire, - transfert par le réseau vers un ou plusieurs n uds secondaires, et - restauration sur le ou les noeuds secondaires.
4. Procédé de réplication selon l'une quelconque des revendications 2 et 3, caractérisé en ce le mécanisme de génération de point de reprise est quasi-synchrone.
5. Procédé de réplication selon l'une des revendications 3 à 4, caractérisé en ce que le mécanisme de génération de point de reprise est incrémental.
6. Procédé de réplication selon l'une des revendications 3 à 5, caractérisé en ce que le mécanisme de génération de point de reprise est discriminant.
7. Procédé de réplication selon l'une des revendications 4 à 6, caractérisé en ce que le mécanisme de génération de point de reprise inclut au moins l'une des fonctions suivantes:
- une barrière de synchronisation de processus (PSB), - une gestion de ressources (RM), - une gestion de ressources système (SRM), et - une gestion de ressources de processus (PRM).
- une barrière de synchronisation de processus (PSB), - une gestion de ressources (RM), - une gestion de ressources système (SRM), et - une gestion de ressources de processus (PRM).
8. Procédé de réplication selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comprend en outre un mécanisme de réplication de fichiers de données applicatives entre le noeud primaire (OP) sur lequel l'application est exécutée et un desdits noeuds secondaires.
9. Procédé pour réaliser une continuité de fonctionnement d'une application logicielle dans une architecture multi-ordinateurs (cluster), cette application étant exécutée à un instant donné sur l'un des ordinateurs du cluster, appelé noeud primaire, les autres ordinateurs dudit cluster étant appelés noeuds secondaires, caractérisé en ce que, en cas de détection d'une défaillance ou d'un événement affectant ledit noeud principal, il met en oeuvre le procédé de réplication selon l'une quelconque des revendications précédentes pour un basculement de service vers lesdits noeuds secondaires.
10. Procédé de continuité de fonctionnement selon la revendication 9, caractérisé en ce que la réplication de l'application est de nature holistique.
11. Procédé de continuité de fonctionnement selon l'une revendications 9 et 10, caractérisé en ce qu'il comprend en outre une mise à jour des clones de l'application.
12. Procédé de continuité de fonctionnement selon l'une des revendications 9 à
11, caractérisé en ce qu'il comprend en outre une supervision de l'état de ressources nécessairement au fonctionnement de l'application.
11, caractérisé en ce qu'il comprend en outre une supervision de l'état de ressources nécessairement au fonctionnement de l'application.
13. Procédé de continuité de fonctionnement selon l'une des revendications 9 à
12, caractérisé en ce qu'il comprend en outre, à la suite d'une détection d'une défaillance ou d'un événement affectant le noeud primaire, une étape pour élire, parmi lesdits noeuds secondaires, un clone, le clone ainsi élu devenant le nouveau noeud primaire.
12, caractérisé en ce qu'il comprend en outre, à la suite d'une détection d'une défaillance ou d'un événement affectant le noeud primaire, une étape pour élire, parmi lesdits noeuds secondaires, un clone, le clone ainsi élu devenant le nouveau noeud primaire.
14. Procédé de continuité de fonctionnement selon l'une des revendications 9 à
13, caractérisé en ce qu'il comprend en outre un enregistrement sur chaque noeud secondaire de messages reçus par le noeud primaire, ces messages étant réinjectés dans le clone élu en cas de basculement.
13, caractérisé en ce qu'il comprend en outre un enregistrement sur chaque noeud secondaire de messages reçus par le noeud primaire, ces messages étant réinjectés dans le clone élu en cas de basculement.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR02/09855 | 2002-08-02 | ||
| FR0209855A FR2843209B1 (fr) | 2002-08-02 | 2002-08-02 | Procede de replication d'une application logicielle dans une architecture multi-ordinateurs, procede pour realiser une continuite de fonctionnement mettant en oeuvre ce procede de replication, et systeme multi-ordinateurs ainsi equipe. |
| PCT/FR2003/002371 WO2004015574A2 (fr) | 2002-08-02 | 2003-07-28 | Continuite de fonctionnement par replication d’un locigiel dans une architecture multi-ordinateurs |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CA2493407A1 CA2493407A1 (fr) | 2004-02-19 |
| CA2493407C true CA2493407C (fr) | 2010-05-11 |
Family
ID=30129640
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA2493407A Expired - Lifetime CA2493407C (fr) | 2002-08-02 | 2003-07-28 | Procede de replication d'une application logicielle dans une architecture multi-ordinateurs, procede pour realiser une continuite de fonctionnement mettant en oeuvre ce procede de replication, et systeme multi-ordinateurs ainsi equipe |
Country Status (9)
| Country | Link |
|---|---|
| US (1) | US7725763B2 (fr) |
| EP (1) | EP1529259B1 (fr) |
| JP (1) | JP2005535044A (fr) |
| AT (1) | ATE434790T1 (fr) |
| AU (1) | AU2003273481A1 (fr) |
| CA (1) | CA2493407C (fr) |
| DE (1) | DE60328100D1 (fr) |
| FR (1) | FR2843209B1 (fr) |
| WO (1) | WO2004015574A2 (fr) |
Families Citing this family (70)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9213609B2 (en) * | 2003-12-16 | 2015-12-15 | Hewlett-Packard Development Company, L.P. | Persistent memory device for backup process checkpoint states |
| US20050216552A1 (en) * | 2004-03-24 | 2005-09-29 | Samuel Fineberg | Communication-link-attached persistent memory system |
| US7475296B2 (en) * | 2004-05-20 | 2009-01-06 | International Business Machines Corporation | Serviceability and test infrastructure for distributed systems |
| FR2872605B1 (fr) * | 2004-06-30 | 2006-10-06 | Meiosys Sa | Procede de gestion d'un processus logiciel, procede et systeme de redistribution ou de continuite de fonctionnement dans une architecture multi-ordinateurs |
| US8122280B2 (en) | 2004-08-26 | 2012-02-21 | Open Invention Network, Llc | Method and system for providing high availability to computer applications |
| US7293200B2 (en) * | 2004-08-26 | 2007-11-06 | Availigent, Inc. | Method and system for providing transparent incremental and multiprocess checkpointing to computer applications |
| FR2881244B1 (fr) * | 2005-01-24 | 2007-05-04 | Meiosys Soc Par Actions Simpli | Procede de comptage d'instructions pour journalisation et rejeu d'une sequence d'evenements deterministes |
| DE602006002967D1 (de) * | 2005-01-28 | 2008-11-13 | Ibm | Zählverfahren für anweisungen zur protokollierung und wiedergabe einer deterministischen ereignisabfolge |
| FR2882165B1 (fr) * | 2005-02-11 | 2007-06-29 | Airbus France Sas | Systeme et procede de traitements embarques d'essais en vol |
| FR2883083B1 (fr) * | 2005-03-14 | 2007-05-04 | Meiosys Soc Par Actions Simpli | Procede d'execution d'une application dans un conteneur virtuel formant une session d'environnement virtualise |
| US7937616B2 (en) * | 2005-06-28 | 2011-05-03 | International Business Machines Corporation | Cluster availability management |
| US7681075B2 (en) | 2006-05-02 | 2010-03-16 | Open Invention Network Llc | Method and system for providing high availability to distributed computer applications |
| US8301700B1 (en) | 2010-08-06 | 2012-10-30 | Open Invention Network Llc | System and method for event-driven live migration of multi-process applications |
| US8195722B1 (en) | 2008-12-15 | 2012-06-05 | Open Invention Network, Llc | Method and system for providing storage checkpointing to a group of independent computer applications |
| US8752049B1 (en) | 2008-12-15 | 2014-06-10 | Open Invention Network, Llc | Method and computer readable medium for providing checkpointing to windows application groups |
| US8584145B1 (en) | 2010-08-06 | 2013-11-12 | Open Invention Network, Llc | System and method for dynamic transparent consistent application-replication of multi-process multi-threaded applications |
| US9043640B1 (en) * | 2005-08-26 | 2015-05-26 | Open Invention Network, LLP | System and method for event-driven live migration of multi-process applications |
| US9141481B1 (en) * | 2010-08-06 | 2015-09-22 | Open Invention Network, Llc | System and method for reliable non-blocking messaging for multi-process application replication |
| US8281184B1 (en) | 2010-08-06 | 2012-10-02 | Open Invention Network Llc | System and method for reliable non-blocking messaging for multi-process application replication |
| US8621275B1 (en) | 2010-08-06 | 2013-12-31 | Open Invention Network, Llc | System and method for event-driven live migration of multi-process applications |
| US8078910B1 (en) | 2008-12-15 | 2011-12-13 | Open Invention Network, Llc | Method and system for providing coordinated checkpointing to a group of independent computer applications |
| US8082468B1 (en) | 2008-12-15 | 2011-12-20 | Open Invention Networks, Llc | Method and system for providing coordinated checkpointing to a group of independent computer applications |
| US8589953B1 (en) * | 2010-08-06 | 2013-11-19 | Open Invention Network, Llc | System and method for transparent consistent application-replication of multi-process multi-threaded applications |
| US20070174484A1 (en) * | 2006-01-23 | 2007-07-26 | Stratus Technologies Bermuda Ltd. | Apparatus and method for high performance checkpointing and rollback of network operations |
| US20070234342A1 (en) * | 2006-01-25 | 2007-10-04 | Flynn John T Jr | System and method for relocating running applications to topologically remotely located computing systems |
| US7904886B2 (en) * | 2006-03-13 | 2011-03-08 | International Business Machines Corporation | Method for executing an application in a virtual container forming a virtualized environment session |
| US7613749B2 (en) | 2006-04-12 | 2009-11-03 | International Business Machines Corporation | System and method for application fault tolerance and recovery using topologically remotely located computing devices |
| GB0611038D0 (en) * | 2006-06-02 | 2006-07-12 | Ibm | Apparatus and method for cluster recovery |
| US8117604B2 (en) * | 2006-07-31 | 2012-02-14 | International Business Machines Corporation | Architecture cloning for power PC processors |
| US7594138B2 (en) | 2007-01-31 | 2009-09-22 | International Business Machines Corporation | System and method of error recovery for backup applications |
| US9384159B2 (en) | 2007-05-24 | 2016-07-05 | International Business Machines Corporation | Creating a checkpoint for a software partition in an asynchronous input/output environment |
| US9473598B2 (en) * | 2007-12-18 | 2016-10-18 | International Business Machines Corporation | Network connection failover during application service interruption |
| US7996094B2 (en) * | 2008-09-09 | 2011-08-09 | Rockwell Automation Technologies, Inc. | Usage of a virtual unit |
| US9354977B1 (en) * | 2008-12-15 | 2016-05-31 | Open Invention Network Llc | System and method for hybrid kernel- and user-space incremental and full checkpointing |
| US8281317B1 (en) | 2008-12-15 | 2012-10-02 | Open Invention Network Llc | Method and computer readable medium for providing checkpointing to windows application groups |
| US8752048B1 (en) | 2008-12-15 | 2014-06-10 | Open Invention Network, Llc | Method and system for providing checkpointing to windows application groups |
| US10019327B1 (en) | 2008-12-15 | 2018-07-10 | Open Invention Network Llc | System and method for hybrid kernel- and user-space incremental and full checkpointing |
| US8341631B2 (en) | 2009-04-10 | 2012-12-25 | Open Invention Network Llc | System and method for application isolation |
| US8745442B1 (en) | 2011-04-28 | 2014-06-03 | Open Invention Network, Llc | System and method for hybrid kernel- and user-space checkpointing |
| US9256496B1 (en) * | 2008-12-15 | 2016-02-09 | Open Invention Network, Llc | System and method for hybrid kernel—and user-space incremental and full checkpointing |
| US8880473B1 (en) * | 2008-12-15 | 2014-11-04 | Open Invention Network, Llc | Method and system for providing storage checkpointing to a group of independent computer applications |
| US8826070B1 (en) | 2008-12-15 | 2014-09-02 | Open Invention Network, Llc | Method and system for providing storage checkpointing to a group of independent computer applications |
| US9058599B1 (en) | 2009-04-10 | 2015-06-16 | Open Invention Network, Llc | System and method for usage billing of hosted applications |
| US11538078B1 (en) | 2009-04-10 | 2022-12-27 | International Business Machines Corporation | System and method for usage billing of hosted applications |
| US9003360B1 (en) * | 2009-12-10 | 2015-04-07 | The Mathworks, Inc. | Configuring attributes using configuration subgraphs |
| US9195500B1 (en) | 2010-02-09 | 2015-11-24 | F5 Networks, Inc. | Methods for seamless storage importing and devices thereof |
| US9135127B1 (en) | 2010-08-06 | 2015-09-15 | Open Invention Network, Llc | System and method for dynamic transparent consistent application-replication of multi-process multi-threaded applications |
| US9286298B1 (en) * | 2010-10-14 | 2016-03-15 | F5 Networks, Inc. | Methods for enhancing management of backup data sets and devices thereof |
| US11307941B1 (en) | 2011-04-28 | 2022-04-19 | Open Invention Network Llc | System and method for hybrid kernel- and user-space incremental and full checkpointing |
| US11625307B1 (en) | 2011-04-28 | 2023-04-11 | International Business Machines Corporation | System and method for hybrid kernel- and user-space incremental and full checkpointing |
| KR101249719B1 (ko) * | 2011-05-04 | 2013-04-03 | 주식회사 인프라웨어테크놀러지 | 어플리케이션 클론 실행 방법, 컴퓨터로 판독가능한 기록매체, 및 이를 지원하는 클론단말 |
| US9020912B1 (en) | 2012-02-20 | 2015-04-28 | F5 Networks, Inc. | Methods for accessing data in a compressed file system and devices thereof |
| US8984336B1 (en) * | 2012-02-20 | 2015-03-17 | Symantec Corporation | Systems and methods for performing first failure data captures |
| US8935568B2 (en) | 2012-07-27 | 2015-01-13 | Dell Products, Lp | System and method of replicating virtual machines for live migration between data centers |
| US9104645B2 (en) | 2012-07-27 | 2015-08-11 | Dell Products, Lp | System and method of replicating virtual machines for live migration between data centers |
| US9201649B2 (en) * | 2012-10-26 | 2015-12-01 | Inforsys Limited | Systems and methods for estimating an impact of changing a source file in a software |
| US9251002B2 (en) | 2013-01-15 | 2016-02-02 | Stratus Technologies Bermuda Ltd. | System and method for writing checkpointing data |
| US9298790B2 (en) * | 2013-01-18 | 2016-03-29 | Microsoft Technology Licensing, Llc | Replication of assets across data centers |
| US10719562B2 (en) | 2013-12-13 | 2020-07-21 | BloomReach Inc. | Distributed and fast data storage layer for large scale web data services |
| WO2015102875A1 (fr) | 2013-12-30 | 2015-07-09 | Stratus Technologies Bermuda Ltd. | Systèmes et procédés d'établissement de points de reprise au moyen d'un réacheminement de données |
| EP3090345B1 (fr) | 2013-12-30 | 2017-11-08 | Stratus Technologies Bermuda Ltd. | Procédé permettant de retarder des points de contrôle par l'inspection de paquets de réseau |
| JP6518672B2 (ja) | 2013-12-30 | 2019-05-22 | ストラタス・テクノロジーズ・バミューダ・リミテッド | 動的チェックポインティングシステムおよび方法 |
| US10834065B1 (en) | 2015-03-31 | 2020-11-10 | F5 Networks, Inc. | Methods for SSL protected NTLM re-authentication and devices thereof |
| US10228962B2 (en) | 2015-12-09 | 2019-03-12 | Commvault Systems, Inc. | Live synchronization and management of virtual machines across computing and virtualization platforms and using live synchronization to support disaster recovery |
| US10387266B2 (en) * | 2015-12-23 | 2019-08-20 | Commvault Systems, Inc. | Application-level live synchronization across computing platforms including synchronizing co-resident applications to disparate standby destinations and selectively synchronizing some applications and not others |
| US10404698B1 (en) | 2016-01-15 | 2019-09-03 | F5 Networks, Inc. | Methods for adaptive organization of web application access points in webtops and devices thereof |
| US11308109B2 (en) * | 2018-10-12 | 2022-04-19 | International Business Machines Corporation | Transfer between different combinations of source and destination nodes |
| US11188386B2 (en) * | 2019-11-01 | 2021-11-30 | Sap Portals Israel Ltd. | Lightweight remote process execution |
| US11327663B2 (en) | 2020-06-09 | 2022-05-10 | Commvault Systems, Inc. | Ensuring the integrity of data storage volumes used in block-level live synchronization operations in a data storage management system |
| US20220382478A1 (en) * | 2021-06-01 | 2022-12-01 | Samsung Electronics Co., Ltd. | Systems, methods, and apparatus for page migration in memory systems |
Family Cites Families (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5852724A (en) * | 1996-06-18 | 1998-12-22 | Veritas Software Corp. | System and method for "N" primary servers to fail over to "1" secondary server |
| US6014686A (en) * | 1996-06-21 | 2000-01-11 | Telcordia Technologies, Inc. | Apparatus and methods for highly available directory services in the distributed computing environment |
| US6360331B2 (en) * | 1998-04-17 | 2002-03-19 | Microsoft Corporation | Method and system for transparently failing over application configuration information in a server cluster |
| US6363416B1 (en) * | 1998-08-28 | 2002-03-26 | 3Com Corporation | System and method for automatic election of a representative node within a communications network with built-in redundancy |
| US6438705B1 (en) * | 1999-01-29 | 2002-08-20 | International Business Machines Corporation | Method and apparatus for building and managing multi-clustered computer systems |
| US7028217B2 (en) * | 2001-06-04 | 2006-04-11 | Lucent Technologies Inc. | System and method of general purpose data replication between mated processors |
| US7093013B1 (en) * | 2002-06-19 | 2006-08-15 | Alcatel | High availability system for network elements |
| US7134044B2 (en) * | 2002-08-16 | 2006-11-07 | International Business Machines Corporation | Method, system, and program for providing a mirror copy of data |
| US7058846B1 (en) * | 2002-10-17 | 2006-06-06 | Veritas Operating Corporation | Cluster failover for storage management services |
| JP4315016B2 (ja) * | 2004-02-24 | 2009-08-19 | 株式会社日立製作所 | コンピュータシステムの系切替方法 |
| US7743372B2 (en) * | 2005-06-28 | 2010-06-22 | Internatinal Business Machines Corporation | Dynamic cluster code updating in logical partitions |
| US7761573B2 (en) * | 2005-12-07 | 2010-07-20 | Avaya Inc. | Seamless live migration of virtual machines across optical networks |
-
2002
- 2002-08-02 FR FR0209855A patent/FR2843209B1/fr not_active Expired - Fee Related
-
2003
- 2003-07-28 CA CA2493407A patent/CA2493407C/fr not_active Expired - Lifetime
- 2003-07-28 DE DE60328100T patent/DE60328100D1/de not_active Expired - Lifetime
- 2003-07-28 JP JP2004526954A patent/JP2005535044A/ja active Pending
- 2003-07-28 EP EP03755641A patent/EP1529259B1/fr not_active Expired - Lifetime
- 2003-07-28 US US10/522,897 patent/US7725763B2/en not_active Expired - Fee Related
- 2003-07-28 WO PCT/FR2003/002371 patent/WO2004015574A2/fr active Application Filing
- 2003-07-28 AT AT03755641T patent/ATE434790T1/de not_active IP Right Cessation
- 2003-07-28 AU AU2003273481A patent/AU2003273481A1/en not_active Abandoned
Also Published As
| Publication number | Publication date |
|---|---|
| EP1529259A2 (fr) | 2005-05-11 |
| EP1529259B1 (fr) | 2009-06-24 |
| FR2843209A1 (fr) | 2004-02-06 |
| AU2003273481A1 (en) | 2004-02-25 |
| WO2004015574A3 (fr) | 2004-09-02 |
| WO2004015574A2 (fr) | 2004-02-19 |
| WO2004015574B1 (fr) | 2004-12-16 |
| ATE434790T1 (de) | 2009-07-15 |
| JP2005535044A (ja) | 2005-11-17 |
| US20050251785A1 (en) | 2005-11-10 |
| US7725763B2 (en) | 2010-05-25 |
| DE60328100D1 (de) | 2009-08-06 |
| CA2493407A1 (fr) | 2004-02-19 |
| FR2843209B1 (fr) | 2006-01-06 |
| AU2003273481A8 (en) | 2004-02-25 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2493407C (fr) | Procede de replication d'une application logicielle dans une architecture multi-ordinateurs, procede pour realiser une continuite de fonctionnement mettant en oeuvre ce procede de replication, et systeme multi-ordinateurs ainsi equipe | |
| US11336685B1 (en) | Cloud-native global file system with rapid ransomware recovery | |
| JP4638905B2 (ja) | データベースのデータ復旧システムおよびその方法 | |
| US8046547B1 (en) | Storage system snapshots for continuous file protection | |
| US9015121B1 (en) | Unified virtual machine and data storage snapshots | |
| Coti et al. | Blocking vs. non-blocking coordinated checkpointing for large-scale fault tolerant MPI | |
| EP1782201A2 (fr) | Procede de gestion d'un processus logiciel, procede et systeme de redistribution ou de continuite de fonctionnement dans une architecture multi-ordinateurs | |
| US20170262345A1 (en) | Backup, Archive and Disaster Recovery Solution with Distributed Storage over Multiple Clouds | |
| US20060282697A1 (en) | Method and system for automated, no downtime, real-time, continuous data protection | |
| US20190347351A1 (en) | Data streaming between datacenters | |
| EP3019987B1 (fr) | Rollback de base de données virtuelle | |
| US20230229562A1 (en) | Continuous data protection using a write filter | |
| US7823153B1 (en) | System and method for detecting and logging in-line synchronization primitives in application program code | |
| CN113886143B (zh) | 虚拟机持续数据保护方法、装置及数据恢复方法、装置 | |
| US10146642B1 (en) | Fault resilient distributed computing using virtual machine continuous data protection | |
| Maloney et al. | A survey and review of the current state of rollback‐recovery for cluster systems | |
| Louati et al. | Gc-cr: a decentralized garbage collector component for checkpointing in clouds | |
| US11907082B2 (en) | Using a stream of source system storage changes to update a continuous data protection-enabled hot standby | |
| US11914480B2 (en) | Standbys for continuous data protection-enabled objects | |
| Aravindhar et al. | An Incremental Snapshot System using Smart Backup for Persistent Disks in Cloud | |
| US11836512B2 (en) | Virtual machine replication strategy based on predicted application failures | |
| CN116954987A (zh) | 一种数据处理方法、装置、存储介质及设备 | |
| WO1997030393A1 (fr) | Systeme informatique a transparence de panne pour les applications utilisateur | |
| Vallée et al. | A framework for high availability based on a single system image |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| MKEX | Expiry |
Effective date: 20230728 |
|
| MKEX | Expiry |
Effective date: 20230728 |