Home header
Linux temps réel embarqué et outils de développements Technique





Rejeu déterministe d'applications multithread
Application aux clusters haute disponibilité par rejeu déterministe

Virtualisation , Hyperviseurs, machines virtuelles et clusters
Ces types d'applications mettent en œuvre les mêmes principes techniques de base, la virtualisation et l'isolation.

1) Présentation des types de virtualisation
2) Cluster haute disponibilité par simple redondance
3) Cluster haute disponibilité par rejeu déterministe (record/replay)

1) Présentation des types de virtualisation

Nous dénombrons quatre types d'applications distinctes utilisant les méthodes de virtualisation et d'isolation:

  • les machines virtuelles de type temps partagé, dont les plus connus sont Vmware, Qemu, Xen,
  • les machines virtuelles de type temps réel, comme Xtratum, RTLinux, ADEOS/Xenomai ou L4 ( L4, L4KA, OK-L4)
  • les clusters haute disponibilité, non déterministes basés sur la redondance simple ou déterministes dont la synchronisation est basée sur le rejeu déterministe des événements (record/replay).
  • et les clusters haute performance.

Nous allons étudier chacune de ces applications de virtualisation et voir pourquoi et comment elles se servent de la virtualisation et de l'isolation.

Mais tout d'abord voyons ce que sont la virtualisation et l'isolation ces deux concepts communs à l'ensemble des hyperviseurs cités plus haut.

La virtualisation

La virtualisation consiste de façon générale à présenter à une application une interface différente de l'interface réelle qu'elle croit utiliser. Le logiciel, présentant cette interface virtuelle est appellé un hyperviseur L'application étant considérée au sens large, l'interface virtuelle présentée par l'hyperviseur peut être:

  • l'interface d'accès réseau, ce qui est le cas dans Linux HA ou carp sous OpenBSD par exemple,
  • l'interface d'accès au processeur, ce qui est le cas dans les émulateurs, comme Qemu sous Windows, Linux ou FreeBSD, Vmware, sous Windows, Linux ou Mac OS-X, Bochs sous Linux,
  • l'interface au système d'exploitation, avec Jockey, LCA sous Linux, MCR sous AIX et Linux
  • l'interface au matériel, avec les hyperviseurs Xen, Xtratum, ADEOS ou L4.

L'isolation

L'isolation consiste à isoler les resources utilisées par l'interface de virtualisation et partagées par les applications virtualisées. Ceci est nécessaire si l'on veut pouvoir

  • Effectuer plusieurs virtualisations en paralelle, pour exécuter plusieurs systèmes d'exploitation simultanément avec Qemu, Vmware, ADEOS ou Xtratum,
  • Arreter et re-démarrer une application virtualisée, ce qui est fait typiquement par Xen ou Vmware lorsque l'on gèle une application pour la re-démarer ultérieurement ou plus spécifiquement par des outils de checkpoint/restart comme BLCR OpenVz ou MCR.
  • Rejouer une application enregistrée pour effectuer une analyse de BUGs,
  • changer une application de serveur, en cas de panne de serveur ou par simple convenance, pour continuer l'application sur un nœud plus efficace.

Certaines ressources sont compliquées à gérer et la difficulté dépend fortement des techniques de virtualisation utilisées et du but de la vritualisation.
L'application de virtualisation la plus compliquée est de réaliser un système de haute disponibilité garantissant le basculement sans interruption de service entre deux ordinateurs pour une application de délivrance de jetons, réservation de billets d'avion, écritures bancaires ...

2) Cluster haute disponibilité par simple redondance

Il existe un grand nombre d'articles et de solutions sur le sujet. Aussi nous ne développons pas cette technique qui est acceptable dans un grand nombre de cas.
Citons par exemple:

  • La redondance à l'aide de LVS, Linux Virtual Server, de Linux-HA dans laquelle Un routeur, ou re-directeur redirige l'activité initialement envoyée à un serveur principal vers un serveur de secours en cas de panne du serveur principal.
    Cette technique est basée sur:
    • le Load Balancer, ldirector
    • le gestionaire de service, mon
    • la détection de présence, Heartbeat
    • la gestion d'adresse virtuelle, LVS

    En particulier utilisée pour les services à base de HTTP, notez qu'il n'est pas possible de gérer simplement HTTPS avec ce système. Pour plus d'information sur ce sujet, nous vous conseillons l'article de unixgarden ou directement le site de LVS ou de Linux-HA

  • La redondance gérée par le DNS utilisée pour les services de mail.

Cette solution, tout à fait acceptable dans de nombreux cas, présente un risque majeur d'erreur dans le cas d'une application multithread de gestion de jetons, comme les systèmes de réservation ou de traitement bancaires. Voyons maintenant comment sécuriser les transactions par le rejeu déterministe d'applications multi threads.

3) Cluster haute disponibilité avec rejeu déterministe (Record/Replay)

Dans les cas plus compliqués, HTTPS, gestion de jetons, il est nécessaire que les différents serveurs réels soient synchrones si l'on veut que le secours prenne la place du principal sans interruption de service.

Voyons dans ce chapitre les différentes resources à virtualiser lorsque on veut pouvoir basculer une application d'un ordinateur à un autre sans interruption de service.

Boite noire et d'état interne

Nous considérons le système de délivrance de jetons comme une boite noire pour l'utilisateur extérieur. Celui-ci n'a aucune idée de ce qu'il se passe à l'intérieur tout ce qu'il veut c'est la garantie du bon fonctionnement de cette boite.
Réciproquement, l'intérieur de cette boite doit rester cohérent avec les information qu'elle a elle même envoyées au monde situé à l'extérieur de la boite et dont les utilisateurs font partie.
En particulier, en considérant la boite noire comme un automate à états, toute modification de l'état interne de la boite transmise au monde doit rester cohérent après la panne éventuelle et le basculement sur l'un des ordinateurs de secours.

Il resulte de ces considérations, que dans le cas ou nous effectuons la mise en haute disponibilité d'un serveur connecté à un réseau toute émission de donnée par l'application contenant une information sur son état interne impliquera la synchronisation préalable des systèmes principal et secours.

Matériel privé ou partagé

A l'intérieur de la boite noire, nous appelons matériel privé, le matériel qui n'est utilisé que par un seul ordinateur et partagé, le matériel qui est commun à l'ensemble du cluster composant la boite noire.

Le matériel partagé doit être considéré comme faisant partie du monde extérieur.

Idempotence des émissions redondantes

Il est relativement évident que tous les accès au matériel privé doivent être dupliqués par chacun des noeuds du cluster afin de garder la cohérence en cas de basculement. Souvenons nous que nous parlons du matériel interne à la boite noire, sans accès depuis ou vers l'extérieur.

En revanche, le matériel partagé par l'ensemble du cluster doit répondre suivant un protocole permettant l'idempotence des informations redondées.
le basculement sur panne n'est par définition pas prévu il devra donc pouvoir se faire à un moment quelconque et en particulier, imaginons la séquence suivante:

  • Le principal passe de l'état interne A vers B
  • Le principal et le secours se synchronisent
  • Le principal doit alors envoyer son état à l'extérieur
  • ---> PANNE !

A ce moment le secours n'a aucun moyen de savoir si l'information est réellement partie ou si elle n'est pas partie vers l'extérieur. Cette information doit pouvoir être réémise par le secours sans transgresser le protocole de communication avec le matériel exterieur.

En particulier, dans le cas de l'utilisation d'une connexion par un réseau, cas des plus probables, le protocole réseau devra lui aussi être soumis à cette règle pour l'acquitement des pacquets entrants, les numéro de séquences émis, les paquets de contrôle ...

Container

En étendant la notion de matériel privé ou partagé à l'ensemble des ressources d'une application, le processeur, la mémoire, on défini la notion de container.
Un container est l'ensemble des resources privées ainsi que les ressources partagées virtualisées et isolées.

Les containers sont gérés par l'hyperviseur. Suivant les applications utilisant la virtualisation et l'isolement on parle aussi de partition (voir Xtratum).

Déterminisme

Revenons au problème initial, et voyons comment, à l'intérieur de la boite noire, l'application peut elle basculer d'un système à l'autre en gardant la cohérence garantissant le bon fonctionnement.

Nous avons vu qu'il est nécessaire que l'état interne, vu par le monde extérieur reste cohérent. Ceci implique qu'à chaque émission d'information vers l'extérieur, l'état interne de l'application existe au niveau du système de secours.

Le transfert complet de l'état interne d'une application est très lourd, il comprends en effet l'ensemble des opérations effectuées en mémoire, le cache du processeur et l'ensemble des registres du processeur plus les opérations en cours avec les périphériques pour le compte de l'application.
Ceci ne peut être réaliser que dans des structures très fortement couplées comme dans les ordinateurs de STRATUS on TANDEM.

Si nous voulons pouvoir éloigner les systèmes, le principal et le secours, nous devrons utiliser un réseau et du fait de la vitesse limitée de propagation de l'information, le ralentissement de l'application pour permettre la synchronisation du secours pourrait être prohibitif, d'où la nécessité de ne transmettre que le minimum d'information.

Si le secours joue la même application dans les mêmes conditions que le principal, nous pouvons nous attendre à ce qu'il soit automatiquement synchronisé avec celui-ci. Ceci n'est pas tout à fait vrais, en effet, pour cela il faudrait que les systèmes soient utilisés d'une façon totalement identique et que les stimulis extérieurs arrivent exactement au même instant, ce qui est impossible à réaliser.

Il est donc nécessaire de synchroniser les systèmes tout en limitant les informations transmises lors de la synchronisation. Les informations qui doivent être transmises entre les deux systèmes sont:

  • Tout stimuli exterieur qui change l'état interne de l'application.
  • Toute action non deterministe engagée par l'ordinateur principal sur l'interface de virtualisation.

Nous verrons les conséquences que cela implique sur l'interface de virtualisation dans un chapitre ultérieur sur la mise en oeuvre de la virtualisation.

Cluster haute performance: HPC

Dans un cluster de haute performance, la mobilité des applications entre noeuds est liée à la possibilité d'arreter une applications sur un noeud, action de checkpoint et de la redémarer sans perte de données ni d'état sur un autre noeud, action de restart.

Checkpoint et Restart

Pour être capable de transférer une application entre deux noeuds, les ressources utilisées sur le premier noeud devrons être disponibles sur le second noeud. Il sera donc, pour les mêmes raisons que dans le cas des clusters haute disponibilité, HAC, nécessaire d'isoler et de virtualiser les ressources utilisées par l'hyperviseur.

Mise en oeuvre de la virtualisation

Nous avons vu que la virtualisation peut être mise en oeuvre à toute interface, réseau, système ou processeur. Il est bien entendu que cette interface doit être étanche, c'est à dire qu'aucune information ne doit la traverser directement sans être gérée par l'hyperviseur.

Quelle interface pour la virtualisation?

Des trois interfaces possibles, réseau, système d'expoitation et processeur, quelle interface utiliser suivant l'application?

Interface réseau

L'interface réseau est simple à mettre en oeuvre, c'est ce qui est utilisé dans Linux-HA pour réaliser des fermes de serveurs sur Internet. Ceci marche très bien, grace à l'idempotence des paquets du protocole TCP/IP tant que l'information est statique.

Si l'information varie au moment d'une panne, rien ne garantie qu'un ticket délivré au client A par le principal ne sera pas réutilisé par le secours pour le client B

Interface processeur et matériel

Nous avons vu que cette interface entraine un très grand flux de données à transmettre d'un système à un autre et ne sera possible que pour des systèmes fortement couplés.

C'est l'interface utilisée par les systèmes d'hyperviseurs temps réel comme Xtratum que nous étudierons plus précisement.

Interface système d'exploitation

C'est l'implémentation que nous allons étudier pour les systèmes HAC et HPC. Comme système d'exploitation exemple nous prendrons le système Linux car c'est le système de type UNIX le plus populaire.

High Availability Cluster avec hyperviseur en espace utilisateur

Choix de l'hyperviseur au niveau de l'interface système

L'implantation d'un hyperviseur de virtualisation au niveau de l'interface système implique d'instrumenter:

  • Tous les appels système émis par l'application
  • Tous les signaux émis par le système à l'attention de l'application
  • Dans le cas d'une application multithread ou d'une application multi-process utilisant de la mémoire partagée, tous les accès de l'application à la mémoire partagée.

Ces informations doivent être transmises du principal au secours afin de rejouer ces opérations à l'identique. L'intérêt de ne transmettre que ces informations est important car il permet de diminuer très sensiblement la quantité d'information à transmettre par rapport à l'instrumentation du processeur. En effet il est inutile de transférer les informations déterministes comme l'exécution d'instructions autre que les appels systèmes exécutés en mode utilisateur, ni tous les accès mémoire effectués sur de la mémoire privée, Le secours peut rejouer l'application initiale et ne devoir se synchroniser que lorsq'une action non déterministe, comme un appel système (en fait comme la plus part des appels systèmes seulement), l'accès à de la mémoire partagée, ou le déroutement du flux d'exécution suite à la réception d'un signal.

Nous allons voir maintenant comment optimiser ces besoins de synchronisation afin de diminuer la flux d'information entre le principal et le secours.

Incidence sur le système d'exploitation

Les trois types d'instrumentation cités ci-dessus ont des implications sur le système d'exploitation, celui-ci doit être capable de:

  • Intercepter les appels systèmes et détourner l'appel vers un hyperviseur
  • Intercepter les signaux et déterminer l'instruction du programme utilisateur qui a été interrompue.
  • Intercepter les accès concurrent à la mémoire partagée afin d'établir l'ordre d'accès des threads à cette mémoire.

Cette instrumentation n'est pas triviale mais elle est nécessaire si l'on veut que le système de secours puisse remplacer le système principal en cas de panne sans perte de cohérence.

Implémentation de l'instrumentation

Il existe deux possibilités pour implémenter l'instrumentation d'une interface:

  • se situer au dessous de l'interface, dans notre cas dans le noyau du système d'exploitation.
  • se situer au dessus de l'interface, dans notre cas dans du coté de l'application.

De nombreux projets utilisent la première méthode, MCR, Openvizi, BLCR. Les problèmes que nous voyons à utiliser une telle méthode sont:

  • la lourdeur de la modification d'un système d'exploitation
  • la dificulté à la maintenir au fur et à mesure des évolutions du noyau du système d'exploitation
  • la nécessité de transiger avec les besoins des autres développeurs noyau pour faire accepter des modifications lourdes. Faute d'acceptation dans le tronc principal le noyau résultant ne sera pas supporté par la plus part des éditeurs de distribution et d'applications.
  • la nécéssité de respecter une licence GPL contraignante.

Nous avons choisi d'utiliser la seconde possibilité, l'instrumentation du coté de l'application.

Interception des appels systèmes

Un patch très légé, Self Ptrace patch permet de générer un signal, SIGSYS, lorsqu'une application instrumentée effectue un appel système. Un utilitaire d'instrumentation, peut alors :

  • mettre en place une routine de gestion des signaux SIGSYS.
  • lancer une application en utilisant un exec userland afin de garder intact le gestionaire de signaux

puis ensuite intercepter tous les appels système et effectuer l'instrumentation nécessaire.

Interception des signaux

Si l'interception des signaux peut sembler simple de prime abord, elle est en réalité beaucoup plus compliquée lorsque l'on considère le déterminisme du flux applicatif.
En effet, les signaux sont transmis du noyau à l'application lors des appels système ou à la fin d'une tranche de temps. Si il est simple de rejouer le premier cas, le second cas est bien plus dificile à rejouer car il faudra connaitre très exactement, non seulement l'instruction qui a été interrompue mais dans le cas de boucles, l'itération qui a été interrompue.
Il y a plusieurs outils pour y parvenir:

  • la modification de la gestion des signaux: en gérant astucieusement le dispatching des signaux par l'hyperviseur on peut éliminer la livraison d'un signal en dehors des appels systèmes.
  • l'utilisation de compteurs intégrés au processeur, compteur d'instruction ou compteur de boucle du mode utilisateur.
  • l'injection de code

Dans le cas où le processeur ne dispose pas de compteur du nombre d'instruction effectuées en mode utilisateur de bonne précision, soit à l'instruction près, il est nécessaire de recourir à l'injection de code.
Le choix de l'adaptation de la méthode de dispatching des signaux par l'hyperviseur permettant de limiter l'injection de code.

Interception des accès concurrent à la mémoire partagée

Dans le cas d'un système de haute disponibilité, si l'on veut rejouer le même flux applicatif sur le système de secours, il est nécessaire d'enregistrer l'ordre des accès à la mémoire partagé.

Pour ce faire, il est nécessaire d'instrumenter le gestionaire de mémoire du système d'exploitation.

Virtualisation, isolation et enregistrement

L'instrumentation étant mise en place elle va permettre d'effectuer la virtualisation et l'isolation des resources ainsi que l'enregistrement des évènements non déterministes qui prennent naissance dans le flux de l'application sur le système proincipal.

Cet enregistrement permettra:

  • soit de garder synchrone un système de secours en lui transmettant l'enregistrement au fur et à mesure du déroulement du flux sur le système principal.
  • ou bien de garder la trace de l'exécution de l'application à fin de la rejouer et de l'analyser en cas de problème.

Virtualisation

Il est nécessaire de virtualiser toute resource dont l'application n'a pas la totale maitrise et qui ne sont pas garantis identiques lorsque l'on fait migrer l'application du système principal au système de secours.

Au niveau des ressources système citons, les PID, les identificateurs d'IPC, les numéros d'inode des fichiers, les labels de disque ...

Les autres ressource qui doivent être virtualisées, sont les données issues de coprocesseurs locaux, comme la date et l'heure, l'accès à un registre au résultat aléatoire comme un coprocesseur de chiffrement.

Virtualisation et isolation

Le système Linux possède des outils permettant l'isolation et la virtualisation de certaines resources système, ce sont les namespaces.

Un namespace pour une resource donnée permet à l'application (ensemble de process) s'exécutant dans ce namespace de croire qu'elle est la seule à utiliser cette resource.
Par exemple le PID namespace effectuera la virtualisation et l'isolation de la resource PID pour le process demandant la création d'un PID namespace et tous ses fils.

Il existe des namespaces pour les resources:

  • PID: Process Identifier
  • IPC: Inter Process Communication system: les identificateurs concernant la mémoire partagée, les messages IPC, les sémaphores.
  • UTSNAME: le nom du système peut être virtualisé
  • USER: le user namespace isole et virtualise les UID, GID
  • NETWORK: le network namespace permet à une application de croire qu'elle est la seule à utiliser une interface spécifique.

Nous n'utilisons pas le USER namespace, nous préférons poser comme contrainte l'identité des UID et des GID entre les systèmes. Les PID namespaces et IPC namespace sont très important pour garantir la virtualisation et l'isolement des applications afin que les identificateurs de resources sur les deux systèmes, principal et secours soient identiques tout au long de la vie du système de haute disponibilité: avant la panne sur le système principal, pendant la panne sur le système de secours lors du basculement et après la panne sur le système de secours en fonctionnement nominal.

Le Network namespace est important pour notre cluster HAC car il va permettre de capturer facilement l'état de la pile TCP/IP sur le principal et de maintenir ainsi la pile TCP/IP sur le secours prête à reprendre la main en cas de panne.

Transfert des enregistrements

Maintenant que l'ensemble de l'instrumentation est prête:

  • Instrumentation des appels système, grace au self ptrace patch deroutant les appels vers l'hyperviseur.
  • Instrumentation des signaux par l'hyperviseur
  • Instrumentation des accès mémoire partagée par le gestionaire de mémoire
  • Instrumentation de la pile TCP/IP pour enregistrer les changements d'état de la pile.

Les enregistrements effectués sur le principal, résultat des appels système, paramètres des signaux, état de la pile TCP/IP, espace mémoire accédé, sont prèts à être transférés sur le secours.

Le protocole de transfert des enregistrements entre le principal et le secours doit obéir à plusieur règles:

  • Les cannaux concernant des espaces de resource différents doivent être désynchronisés. En effet de même qu'un thread ne doit jamais dormir sans lacher l'ensemble de ses resources locales, un canal transmettant des informations sur une resource ne doit jamais bloquer les canaux des autres resources.
  • Par exemple, les canaux d'information des appels système et des signaux sont des resources au niveau d'un thread et sont disjointes d'un thread à l'autre. Ces informations pourrons utiliser le même canal quelque soit le thread.
  • les informations concernant des accès à des resources partagées, par exemple un fichier partagé, sont des informations au niveau système et devront aussi avoir un canal réservé.
  • Les informations concernant les accès à la mémoire partagée sont des resources au niveau du processeur, un seul processeur doit un accéder à la fois pour garantir l'ordonancement. Ces informations devront avoir un canal réservé.
  • Les informations concernant la pile TCP/IP devront avoir un canal réservé.
  • L'ensemble des cannaux devra être purgé vers le système de secours avant toute émission de données sur le réseau.

Pour garantir l'ensemble de ces règles, nous avons utilisé un protocole de type ISO-TP4 avec acquitement sélectif.

Phases dans un HAC (High Availability Cluster)

Une application de haute disponibilité par Record et Replay se prête très bien à une description conforme aux recommendations dur l'interconnection de systèmes ouverts (OSI).

Synchronisations

Nous avons vu ci-dessus les synchronisations, la synchronisation mineure nécessaire lors des transfert des enregistrements entre les deux systèmes, principal et secours, à synchroniser, et la synchronisation majeure effectuée avant l'émission d'information vers le monde extérieur.

Cependant nous n'avons présenté que le système dans une phase de fonctionnement établi et nous n'avons laissé de coté l'établissement initial du lien entre les deux systèmes.

Activités

Dans un système de haute disponibilité, nous ne pouvons pas partir du principe qu'il n'y aura pas de panne, aussi il convient d'établir comment nous allons retirer ou ajouter un système de secours à un système en mode de fonctionnement établi.

L'ajout d'un système de secours et son retrait doivent être gérés comme des activités. Comme pour les activités de la couche 5 de l'OSI, l'ajout d'un système de secours doit être effectué avec un point de synchronisation majeure. De même l'ajout d'un système de secours doit faire l'objet d'une resynchronisation.

La resynchronisation d'une activité de record/replay est effectuée à l'aide d'une application de checkpoint/restart. Il faut noter que cette opération est une opération planifiée, qui peut échouer et être effectuer de nouveau sans conséquence sur le bon fonctionnement du système principal.

Checkpoint/Restart avec l'instrumentation en espace utilisateur

L'instrumentation mise en oeuvre pour le record et replay peut être utilisée pour effectuer le checkpoint et restart d'une applications instrumentée.

L'intérêt d'utiliser une instrumentation dans l'espace utilisateur est multiple,

  • il n'est pas nécessaire de modifier le noyau, d'ou un gain considérable en acceptance par la communauté Linux
  • il n'est pas nécessaire de prendre une image du noyau pour le checkpont, l'ensemble des données est en espace utilisateur et donc plus simple à sauvegarder
  • il n'y a pas de risque de perte de données, les messages en transit, les signaux non délivrés sont intercepté avant d'entrer dans le noyau pour le coté émetteur et avant d'être délivré du coté récepteur.

Contrairement aux opérations de mobilités des clusters HPC effectuées par checkpoint et restart, les opérations de resynchronisation dans les clusters HAC ne stoppent pas l'application sur le système principal mais le redémarent avec une instrumentation de type record
De même, l'application sur le secours n'est pas re-démarrée vraiment mais elle est re-démarrée avec une instrumentation de replay.
Dans un cluster HAC par record/replay, le secours, effectuant le replay n'effectue aucun accès au monde extérieur tant que le principal fonctionne normalement.

Intégration dans un système de surveilance

Un logiciel de contrôle permet de démarer l'hyperviseur et de le contrôler. Il s'interface simplement par socket avec tout utilitaire Shell ou script de l'espace utilisateur et peut ainsi facilement s'intégrer avec un logiciel de surveillance comme Tivoli, Openview ou des systèmes OpenSource comme nagios ou Zabbix.

Le système de surveillance est responsable de la détection des pannes, de l'implémentation du Heartbeat, du routage, de la translation d'adresse et de la gestion des adresses virtuelles, ainsi que des décisions prises sur la détection des pannes.

Noter que le système d'instrumentation, envoie au système de surveillance les informations sur les erreurs de synchronisation et sur les erreurs détectées sur le principal ou sur le secours mais n'effectue aucune correction par lui même.

Conclusion sur le cluster HAC

Le système de cluster HAC comporte quatre petits patchs noyau pour Linux pour réaliser:

  • la dérivation des appels systèmes vers l'hyperviseur
  • la gestion de l'ordonancement des accès à la mémoire partagée
  • l'instrumentation de la pile TCP/IP
  • la synchronisation des cannaux de transfert des évènements

Il comporte aussi un hyperviseur dans l'espace utilisateur de l'application instrumentée et un outil, programme utilisateur, de lancement et de contrôle de l'hyperviseur.

Les développements futurs pourrons être:

  • l'utilisation de l'instrumentation à fin de debug, par exemple pour rejouer les derniers instants d'une application avant sa mort.
  • l'insertion d'une couche de Présentation de type OSI niveau 6, pour permettre de rejouer l'enregistrement sur un système de secours possédant une architecture différente de l'architecture du système principal.
    En effet, comme seuls sont enregistrés les résultats des appels système, il semble possible de virtualiser cette interface aussi.

Remerciements

Je remercie, Marc Vertes et Philippe Bergeaud, de MEIOSYS puis IBM, qui sont à la source de nombreuses idées, développées ici, ainsi que la société IBM grace à laquelle j'ai pu implémenter une partie des développements présentés, sur zLinux dans le cadre du projet LCA.

Xtratum

Nous étudions plus précisement Xtratum sur cette page: http://mnis.fr/france/services/xtratum/. Une présentation par les auteurs est disponible sur: http://www.xtratum.org/doc/papers/xtratum_overview_OSPERT2005.pdf.

Liens et Bibliographie
©M.N.I.S Société | Produits | Services | Formations | Support | Partenariat | Presse | Téléchargements ©M.N.I.S