FR2794876A1 - Procede de reconfiguration d'un systeme de traitement de l'information sur detection de defaillance d'un composant - Google Patents

Abstract

L'invention concerne un procédé de reconfiguration dynamique d'un système de traitement de l'information (1), notamment d'un système multiprocesseur symétrique dit " SMP ". Le procédé comprend une étape préliminaire de détection d'un risque de défaillance d'un des composants du système (CPU3 ). Après cette détection, il comprend une première étape consistant à amener le système (1) à un état cohérent dit de " gel ", à l'aide de programmes (J1 -J4 ) exécutant des tâches spécifiques, une deuxième étape consistant à le reconfigurer, en ré-allouant/ dé-allouant tout ou partie des composants (CPU1 -CPU4 ) et une troisième étape consistant à isoler le composant (CPU3 ) présentant un risque de défaillance. Les interruptions pendantes (4) sont traitées et les tâches en cours (6) sont exécutées, avant " gel " De même, les files d'attente de tâches à exécuter sont purgées avant " gel " Ensuite, les tâches et interruptions subséquentes sont bloquées, jusqu'à une étape finale qui consiste en la libération du système (1).

Description

PROCÉDÉ DE RECONFIGURATION D'UN SYSTÈME DE TRAITEMENT DE L'INFORMATION SUR DÉTECTION DE DÉFAILLANCE D'UN COMPOSANT L'invention concerne un procédé de reconfiguration dynamique "à chaud" d'un système de traitement de l'information sur détection de défaillance d'au moins un composant.

L'invention s'applique plus particulièrement aux systèmes multiprocesseurs, et plus particulièrement encore aux systèmes multiprocesseurs symétriques, du type dit "SMP" selon la terminologie anglo-saxonne.

Dans le cadre de l'invention, le terme "composant" doit être considéré dans son sens le plus général. II englobe aussi bien des composants matériels, par exemple un processeur dans un système de type "SMP" précité, ou des composants logiciels, par exemple un des modules du système d'exploitation.

Le terme "défaillance" doit également être compris dans son sens le plus général. II peut être naturellement relatif à des composants en panne. Cependant, dans le cadre de l'invention, il concerne le plus souvent un ou plusieurs composants présentant un risque élevé de tomber réellement en panne.

Ce sont généralement des situations pour lesquelles un paramètre associé au fonctionnement d'un des composants du système passe au-dessus ou en dessous d'un seuil critique prédéfini. Pour fixer les idées, on prendra l'exemple de la détection et de la correction d'erreurs sur des données enregistrées dans une mémoire vive d'un processeur. II est habituel d'enregistrer des données redondantes en sus des données réellement utiles, et d'utiliser un mécanisme de correction d'erreur connu sous le sigle anglo-saxon "ECC" (pour "Error Correcting Code"). Ce mécanisme utilise les données redondantes pour corriger les erreurs détectées. Cependant, on peut décider, à titre préventif, de considérer tout ou partie de cette mémoire vive comme étant défaillante, si le taux d'erreurs détectées franchit un seuil prédéterminé, et de ne plus utiliser cette mémoire ou partie de mémoire.

On conçoit aisément que la mise "hors circuit" d'un composant, quel qu'il soit, pose un certain nombre de problèmes, et ne peut être effectuée sans précautions particulières. Ce composant constitue en effet ce qu'on appelle une ressource informatique (matérielle ou logicielle) du système de traitement de l'information. Tout d'abord, s'il est en cours de fonctionnement (par exemple traitement d'une tâche, s'il s'agit un processeur) ou utilisé par d'autres composants du système, il ne peut être arrêté immédiatement. II est nécessaire que le traitement en cours se termine, ou pour le moins soit pris en charge par d'autres composants. Dans le cas contraire, des dysfonctionnements graves et irrémédiables (pertes de données, etc.) pourraient intervenir. Ensuite, il va être nécessaire d'isoler le composant défaillant des autres parties du système. II est enfin le plus souvent nécessaire de reconfigurer le système, en attendant de réparer le composant défectueux et/ou de le remplacer.

Toutes ces opérations, et en particulier les deux dernières nécessitent un arrêt de tout ou partie du système.

Pour certaines applications, mettant en oeuvre des systèmes dits à haute disponibilité, un arrêt du fonctionnement est inacceptable.

Or, et même en dehors du champ de ces applications spécifiques, les besoins actuels convergent vers cette exigence de haute disponibilité.

D'un point de vue de l'utilisateur ou du client, la notion de haute disponibilité constitue souvent un critère majeur dans le choix d'un système. II est courant qu'un fonctionnement continu, c'est-à-dire 24 H x 24 H, 7 jours sur 7, soit désormais envisagé.

Le matériel devient de plus en plus complexe et spécialisé, ce qui implique corrélativement une plus grande fiabilité pour obtenir au moins les mêmes disponibilités et longévité que dans le passé, étant entendu que les exigences présentes tendent à augmenter. Ces exigences sont les plus critiques pour les systèmes de très grandes capacités, connus sous l'appellation anglo- saxonne "main-frames".

II s'ensuit que de nouvelles procédures de maintenance ont dû être mises en oeuvre : toutes les interventions de maintenance doivent être désormais planifiées. Le but est de perturber de façon minimale le bon fonctionnement du système. En effet, toute maintenance non planifiée est génératrice de coûts et/ou de pertes très importantes. Ces pertes et coûts ont naturellement aussi un impact important sur la confiance accordée par l'utilisateur ou le client. En ce qui concerne plus particulièrement les composants logiciels, il existe un problème spécifique. II est nécessaire de remplacer des composants susceptibles de tomber en panne, ce qui conduit très généralement à un arrêt de la machine. Or la machine, selon les exigences précitées devrait continuer à fonctionner, ce qui apparaît incompatible.

Aussi dans l'art connu, on a proposé des solutions qui tendaient à assurer la haute disponibilité précitée. Pour ce faire, on fait appel à des solutions que l'on qualifiera de "matérielle". Ces solutions impliquent généralement une configuration spécifique, et font éventuellement appel à des pilotes logiciels aussi spécifiques.

Ces solutions peuvent être classifiées comme suit - un branchement en fonctionnement dit "hot-plug" : il s'agit d'un sous- ensemble de circuits spécialisés qui permet d'isoler, de débrancher et de remplacer les composants dits en panne ; - une architecture de machines dite "en grappe", ou "cluster", dans laquelle plusieurs machines travaillent ensemble : si une des machines tombe en panne, une autre machine, appartenant à l'ensemble, la remplace, profitant du fait que les données sont redondantes et réparties parmi ces machines ; et - une redondance matérielle (dite "multipath" ou à chemin multiple), dans laquelle deux ou plusieurs composants travaillent en parallèle : si un des composants tombe en panne, les autres composants en parallèles prennent le relais.

Dans cette dernière variante, on place aussi la redondance triple avec un vote majoritaire ("deux parmi trois").

Toutes ces solutions présentent des inconvénients - un branchement en fonctionnement du type "hot-plug" implique l'existence de circuits spécialisés, ce qui, à son tour, engendre une complexité accrue du système et une augmentation corrélative du coût de fabrication, et la méthode exige un support spécial de la part du système d'exploitation et ne peut pas être appliquée après coup aux systèmes existants ; - par nature, une grappe de machines, ou "cluster, est constituée d'au moins deux machines complètes : la redondance en matériel est donc importante et la nécessité de disposer d'un système d'exploitation spécifique pour ce type d'architecture de système représentent un coût très élevé ; et - la redondance en matériel est,<I>a priori,</I> la plus coûteuse des techniques, car elle implique une démultiplication de tous les composants constituant le système, ou pour le moins de la plupart d'entre eux.

L'invention vise à pallier les inconvénients des procédés et dispositifs de l'art connu, et dont certains viennent d'être rappelés.

L'invention se fixe pour but un procédé permettant de répondre aux besoins qui se font sentir, sans présenter les inconvénients des procédés et dispositifs selon l'art connu, dont certains viennent d'être rappelés.

Selon le procédé de l'invention, il n'est notamment plus requis de prévoir une quelconque redondance en matériel.

Pour ce faire, selon une première caractéristique importante, le procédé selon l'invention comprend des étapes permettant, sur détection d'une défaillance d'un composant, le "gel" momentané du système, d'une façon que l'on peut appeler "à chaud" ou "à la volée", c'est-à-dire d'arrêter, de façon ordonnée, toutes les activités en cours à un point d'exécution dit cohérent du fonctionnement système. Ce "gel" consiste en un mécanisme de mutuelle exclusion.

Le terme "défaillance" doit être entendu dans le sens qui a été précédemment précisé, c'est-à-dire généralement un risque évalué de panne.

Dès que cet état est obtenu, il est alors procédé à une reconfiguration du système. II devient en effet possible de procéder à une ré-allocation ou une dé- allocation dynamique de toute ressource du système, qu'elle soit matérielle ou logicielle : processeur, mémoire, module logiciel (y compris une partie du système d'exploitation), ou tout autre composant.

Pour ce faire, selon une autre caractéristique importante de l'invention, on met en ceuvre des processus ou tâches spécifiques, se déroulant en mode non préemptif et de façon synchronisée, sous la conduite d'un des processus dit maître, ou d'un composant en tenant lieu.

Le composant défaillant est alors isolé du système.

Enfin, le système d'exploitation du système est de nouveau libéré et le système peut fonctionner normalement de nouveau. On doit bien comprendre que toutes les étapes précédentes sont restées transparentes, et pour le système d'exploitation, et pour l'utilisateur (administrateur du système, etc.), et enfin pour les applications utilisateurs. II a d'ailleurs été rappelé que le composant défaillant pouvait être l'un des modules du système d'exploitation lui-même.

Les seules contraintes imposées sont, de façon pratique, les suivantes - le délai d'exécution doit être raisonnable, c'est-à-dire compatible avec le type d'application envisagée et/ou le type de machines mises en oeuvre (vitesse de fonctionnement, cycle d'horloge de base, etc.) ; et - la dégradation des performances qui résultent de la reconfiguration (isolement du composant déclaré défaillant) doit être imperceptible, ou pour le moins très peu sensible.

Si la première condition est difficile à réaliser, il est possible, selon une variante du procédé, au moins pour certaines applications, de segmenter le processus. En d'autres termes, on procède en plusieurs phases successives, chaque phase permettant de réaliser une partie du processus global jusqu'à complétion.

Dans une variante préférée de l'invention, le procédé s'applique aux systèmes multiprocesseurs, notamment aux systèmes dits "SMP", comme il a été rappelé, et plus particulièrement encore à un environnement de système d'exploitation de type "UNIX" (marque déposée). Mais on doit bien comprendre que le procédé de l'invention s'applique à la grande majorité des architectures de systèmes de traitement de l'information, à la condition que certaines caractéristiques fonctionnelles minimales, qui seront spécifiées ci-après, soient satisfaites.

L'invention a donc pour objet un Procédé de reconfïguration d'un système de traitement de l'information comprenant des composants formant des ressources matérielles et logiciels, et fonctionnant sous la commande d'un système d'exploitation déterminé, dans lequel s'exécute au moins une application dite d'utilisateur, caractérisé en ce qu'il comprend au moins les étapes suivantes - une étape préliminaire consistant à détecter un risque préétabli de défaillance sur au moins un desdits composants ; - une première étape consistant, après ladite détection de risque de défaillance, à lancer au moins un programme spécifique pour l'exécution d'une tâche spécifique (J1-J4), sous la commande dudit système d'exploitation, en mode non préemptif, de manière à amener ledit système de traitement de l'information à un état prédéterminé cohérent dit "gelé", dans lequel chacune desdites applications d'utilisateur en cours d'exécution est stoppée de façon ordonnée et aucune autre application autorisée à s'exécuter ; - une deuxième étape à exécuter ladite tâche spécifique pour reconfigurer ledit système de traitement de l'information en effectuant des opérations de ré- allocation et/ou dé-allocation de tout ou partie desdits composants de ce système, de manière à préparer l'isolation de chacun desdits composants pour lequel ledit risque préétabli de défaillance a été détecté ; - une troisième étape consistant à isoler chacun desdits composants pour lequel ledit risque de défaillance a été détecté, de manière à ce qu'il ne soit plus reconnu par ledit système de traitement de l'information et ne constitue plus l'une desdites ressources ; et - une étape finale de libération dudit système de traitement de l'information autorisant de nouveau son fonctionnement et l'exécution d'au moins une desdites applications d'utilisateur.

L'invention va maintenant être décrite de façon plus détaillée en se référant aux dessins annexés, parmi lesquels - la figure 1 illustre schématiquement un exemple d'architecture multiprocesseur symétrique du type dit "SMP" ; - la figure 2 est un organigramme explicitant les choix possibles en cas de détection d'un élément défaillant dans l'architecture de la figure 1 ; - la figure 3 illustre de façon plus détaillée l'architecture de la figure 1 pour la mise en oeuvre du procédé de reconfiguration dynamique selon l'invention ; - la figure 4 est un diagramme illustrant les principales étapes du procédé de reconfiguration dynamique selon l'invention ; et - la figure 5 illustre schématiquement une étape particulière de ce procédé. Dans ce qui suit, sans en limiter en quoi que ce soit la portée, on se placera ci-après dans le cadre de l'application préférée de l'invention, sauf mention contraire, c'est-à-dire dans le cas d'un système multiprocesseur symétrique dit "SMP", et dans un environnement de système d'exploitation de type "UNIX".

La figure 1 iflustre schématiquement une telle architecture. Le système 1 représenté comprend quatre processeurs, CPU1 <I>à</I> CPU4.

On considérera, toujours dans un but de simple illustration du procédé, que le composant du système 1 susceptible de défaillance est l'un des processeurs, CPU1 <I>à</I> CPU4. Aussi, pour simplifier le dessin, on n'a pas représenté les autres composants habituels du système 1 (mémoire partagée, mémoires de masse, périphériques divers, etc.). Pour faciliter la description, on a également supposé que le système comprend un organe centralisé 2, pour la détection d'erreurs. Dans la pratique, la détection du risque d'erreurs est effectuée par le composant potentiellement défaillant, composant matériel ou logiciel, et non par un organe extérieur.

Comme il a été indiqué, la détection d'un risque de défaillance d'un des composants est généralement obtenue par la surveillance de paramètres pré établis et du franchissement de seuils déterminés associés à ces paramètres, ou par des procédés similaires. L'organe 2 de détection de composants défaillants communique avec le système d'exploitation 3. On a également représenté, sur la figure 1, un contrôleur d'interruptions 4. De façon usuelle, des signaux d'interruption, de niveaux déterminés, sont transmis aux différents processeurs, selon le type de tâche à accomplir et selon l'organe périphérique (non représenté) qui l'initie.

On suppose que le processeur CPU3 est détecté potentiellement défaillant par l'organe de détection 2.

La figure 2 est un organigramme représentant les alternatives qui peuvent être prises dans cette circonstance. En 50, l'organe de détection d'erreur émet un signal spécifique indiquant que le processeur CPU3 est déclaré défaillant. En 51, le système d'exploitation peut décider d'ignorer cet avertissement (branche "OUI"), ce qui peut se traduire par un arrêt non voulu du système 1 ou "crash", le CPU3 tombant réellement en panne et pouvant causer un dysfonctionnement préjudiciable et/ou des dégâts irréversibles (pertes de données, etc.). Si l'avertissement n'est pas ignoré (branche "NON"), l'action réalisée, en 52, peut consister, soit en un arrêter volontaire du système 1 (pour procéder à une opération de maintenance, volontaire maïs non programmée), en 53, soit en une reconfiguration dynamique "à chaud", en 54. Si on arrête le système, il est clair que, même si les conséquences sont,<I>a priori,</I> moins graves que dans la première alternative considérée (ignorer l'avertissement), la disponibilité du système ne peut plus être assurée, du fait précisément de cet arrêt. La reconfiguration dynamique "à chaud" concerne, pour sa part, directement le procédé selon l'invention.

On va maintenant se référer à la figure 3 qui illustre, de façon plus détaillée que sur la figure 1, les principaux éléments qui interviennent dans le procédé de reconfiguration dynamique "à chaud" selon l'invention.

Les éléments communs à la figure 1 portent les mêmes références et ne seront re-décrits qu'en tant que de besoin.

Puisque l'organe détecteur d'erreur 2 a détecté la défaillance du processeur CPU3, ce dernier, selon une caractéristique important de l'invention, doit être désactivé, c'est-à-dire, en d'autres termes, isolé du système 1.

On a représenté, sur la figure 3, trois "fonctions" majeures qui caractérisent le fonctionnement d'un système de traitement de l'information, à savoir le système d'exploitation "OS" 3, une fonction, que l'on qualifiera de logicielle, qui concerne les tâches utilisateurs 6, en cours de traitement dans un ou plusieurs processeurs, et une fonction, que l'on qualifiera de matérielle, les interruptions externes générées par un ou plusieurs contrôleurs d'interruptions, symbolisés par un organe unique 4. Dans le cadre de l'invention, le terme "tâche" doit être compris dans son sens le plus général. La terminologie utilisée dépend d'ailleurs de l'environnement considéré (système d'exploitation). Le terme "tâche" englobe notamment les termes français ou anglo-saxons suivants : "processus", " thread", "task" ou "job".

Pour que le processeur CPU3 soit effectivement désactivé, il est donc nécessaire qu'il n'intervienne plus dans aucune des fonctions ci-dessus, ou qu'il ne soit plus sollicité par celles-ci. Cet état a été symbolisé par des "X" sur la figure 3. Cependant, ce n'est pas la seule condition à remplir. Il est en effet nécessaire qu'aucune tâche ne soit plus exécutée par ce processeur, tant qu'il n'est pas réparé ou remplacé. Il est aussi nécessaire que les tâches entamées se terminent normalement, pour éviter tout dysfonctionnement et/ou pertes de données. II est également nécessaire que les interruptions en cours soient traitées normalement.

II est enfin nécessaire de maîtriser ce qui s'exécute sur les autres processeurs, c'est-à-dire, dans l'exemple décrit, les processeurs CPU1, CPU2 et CPU3. En effet, dans le système multiprocesseur 1, un ou plusieurs processeurs, par exemple le processeur CPU1, peu(ven)t demander à avoir accès aux tâches en cours de traitement dans le processeur CPU3, ou lui transmettre une tâche à accomplir ou des données. Ce risque est d'autant plus élevé qu'il s'agit d'un système multiprocesseur de type "SN1P", c'est-à-dire symétrique comme il a été rappelé. Le système d'exploitation "OS" 3 ne maîtrise pas entièrement la répartition des tâches, du fait précisément de l'entière symétrie du système.

Aussi, selon une caractéristique fondamentale du procédé selon l'invention, on va "geler" le système 1 en sa globalité, et non plus seulement le composant défaillant ou déclaré comme tel. Ce "gel" ne dure cependant qu'un lapse de temps très court. Le qualificatif "court" doit être entendu par rapport à la nature des applications traitées dans le système et à d'autres caractéristiques fonctionnelles (rapidité des processeurs, temps de cycle, etc.). Selon une autre caractéristique importante, le "gel" du système 1 est transparent pour un utilisateur et pour le système d'exploitation.

La figure 4 est un organigramme 6 montrant les principales étapes du procédé selon l'invention.

En 60, l'organe de détection d'erreur 2 détecte une défaillance du processeur CPU3, comme décrit précédemment.

La première étape 61, que l'on appellera ci-après étape de "maîtrise", consiste précisément à obtenir la maîtrise des fonctions rappelées ci-dessus. Pour ce faire, lors d'une première étape, on associe à chacun des processeurs CPU1 <I>à</I> CPU4, une tâche spécifique. Ces tâches sont exécutées par des programmes ou pièces de logicielles spécifiques, sous la commande du système d'exploitation "OS" 3. On appellera ces tâches spécifiques "jobs, en l'occurrence J1 à J4, et de façon plus générale, J1 à Jn, si le système comporte n processeurs. On doit bien noter qu'un job, J3, est associé au processeur défaillant CPU3. Selon une autre caractéristique, les jobs sont d'un type non préemptif, même si le système d'exploitation permet ce mode de fonctionnement. Le travail s'effectue en mode exclusif. Les jobs sont synchronisés entre eux et sont sous la commande d'un composant du système dit "maître".

De façon avantageuse, c'est l'un des jobs spécifiques, J1 à J4, qui joue ce rôle. La synchronisation est obtenue généralement au travers d'un organe de mémoire centrale (non représenté) qui reste en mode partagé. La synchronisation peut s'effectuer de toute manière connue, par exemple par un masque de bits.

De cette façon, le job maître attend que les autres jobs aient fini d'exécuter des actions ou tâches qui leur sont spécifiques. II peut également distribuer aux autres jobs des tâches à accomplir.

Les jobs spécifiques ne doivent pas non plus être interrompus par des interruptions externes. Pour ce faire, le système d'exploitation 3 agit sur le contrôleur d'interruptions 4 (figure 3).

Par ce mécanisme, le fonctionnement du système 1 est entièrement maîtrisé et celui-ci est amené, de façon prévisible et ordonnée, à un état prédéterminé.

Cet état va permettre de passer à l'étape suivante, ou étape de reconfiguration 62. Pendant cette étape, les jobs spécifiques, J1 à J4, "recomposent" l'architecture matérielle et logique du système 1, de façon à tenir compte de la défaillance du processeur CPU3. De façon pratique, cela se traduit par la mise à jour de tables de configuration, ou d'éléments semblables, et la ré- affection des ressources composant le système 1, ce en vue de désactiver le processeur CPU3.

L'étape 63 consiste en l'isolation effective du processeur défaillant CPU3. Celui-ci ne sera plus alors reconnu par le système d'exploitation 3 (figure 3). En d'autres termes, il ne figure plus dans la liste des ressources disponibles. La dernière étape 64 consiste en la libération du système d'exploitation 3, ce qui permet au système 1 de fonctionner de nouveau. Les interruptions externes peuvent alors être de nouveau transmises aux processeurs restants, CPU1, CPU et CPU4, et les tâches 6 distribuées sur ces processeurs.

Selon une autre caractéristique du procédé de l'invention, les jobs spécifiques, J1 à J4, "s'auto-anéantissent", c'est-à-dire se terminent de façon spontanée, au plus tard lors de l'étape terminale 63 de libération du système d'exploitation 3.

Pour que le procédé de reconfïguration dynamique "à chaud" selon l'invention se déroule correctement, il est nécessaire que le "gel" effectif du système soit obtenu à l'intérieur d'un lapse de temps maximal, comme il a été rappelé. Pour ce faire, il suffit de définir une valeur d'intervalle de temps prédéterminée une fois pour toutes ou déterminée en fonction des applications en cours de traitement. Cet intervalle de temps est généralement appelé "time-out", selon la terminologie anglo-saxonne. Ce paramètre est appelé en début de l'étape 61, ou préalablement à l'initiation de celle-ci, et comparé à un signal d'intervalle de temps délivré par un circuit d'horloge approprié. Il doit être remarqué que toutes les fonctionnalités du système 1 ne sont pas "gelées", même si celui-ci l'est globalement selon la caractéristique principale du procédé de l'invention. La majorité des ressources matérielles continue de fonctionner et reste disponible. C'est notamment le cas des circuits de génération de signaux d'horloge. II est donc possible, par exemple d'utiliser un des compteurs du système, alimenté par des signaux d'horloge, pour déterminer si les opérations des étapes 61 à 63 sont comprises dans le 'intervalle de temps imparti.

Si le processus est trop lent et ne peut s'effectuer à l'intérieur de cet intervalle de temps imparti, il est possible, dans une variante du procédé, de "l'atomiser", c'est-à-dire de le segmenter en une suite de phases successives de "gels" provisoires, entrecoupées de libérations du système d'exploitation. De cette façon, le système 1 est amené progressivement dans un état permettant l'isolation effective du composant défaillant, par exemple le processeur CPU3. Celle-ci est réalisée lors de la dernière phase de "gel", à la suite de quoi le système d'exploitation est définitivement libéré, la nouvelle configuration du système 1, excluant le composant défaillant, étant obtenue.

Généralement, il est nécessaire de procéder à des étapes supplémentaires. Ces étapes consistent, non seulement à terminer les tâches en cours, comme il a été précédemment rappelé, mais aussi à exécuter les tâches en attente de traitement, notamment dans le processeur défaillant CPU3. D'autre part, il est également nécessaire de traiter les interruptions en attente. Dans le cas contraire, les tâches correspondantes risqueraient d'être irrémédiablement perdues.

La figure 5 illustre schématiquement une des étapes supplémentaire. De façon habituelle et bien connue, le système 1 est associé à des files d'attente, représentée sous la référence générale 7, qui reçoivent une liste de tâches à traiter de façon prioritaire. II s'agit généralement de dispositifs de mémoire de type dit "premier entré - premier sorti", ou "FIFO" selon la terminologie anglo- saxonne. Ces dispositifs déterminent l'ordre dans lequel doivent être traitées les tâches. II est donc nécessaire d'effectuer une opération que l'on qualifiera de "purge" de la file d'attente 7, pour la vider. En outre, pour éviter qu'elle se remplisse de nouveau, il est également nécessaire de bloquer les tâches "à la source". Le système 1 est généralement muni d'un organe dit "dispatcher" 8 (ordonanceur de tâches) ou organe similaire, dont le rôle est précisément de répartir les tâches à traiter, en tenant compte notamment de leurs priorités relatives. On agira donc sur l'organe 8 pour obtenir le blocage à la source précité. Cette action peut s'effectuer sous la commande d'un des jobs spécifiques. Le fonctionnement normal de cet organe 8 est de nouveau autorisé après libération du système d'exploitation (figure 4 : étape 64). compte tenu que le système 1 est alors reconfiguré et le composant défaillant (le processeur CPU3 dans l'exemple décrit) dé-alloué, les tâches qui auraient pu lui être destinées sont (re-)dirigées vers un des processeurs valides, CPU1, CPU2 ou CPU4.

En ce qui concerne les interruptions externes, et si on se reporte de nouveau à la figure 3, il suffit de bloquer temporairement le fonctionnement du contrôleur d'interruptions 4, tout en autorisant l'exécution des interruptions en cours. Cette opération, symbolisé par un "X" sur les sorties du contrôleur d'interruptions 4, peut également être réalisée sous la commande de l'un des jobs spécifiques. Comme précédemment, le fonctionnement du contrôleur d'interruptions 4 sera de nouveau autorisé et les interruptions également de nouveau prises en compte après libération du système d'exploitation (figure 4 étape 64). La même constatation que précédemment s'impose : les nouvelles interruptions ne pourront plus être dirigées sur le processeur CPU3, qui n'est plus connu du système d'exploitation 3 et, donc, du contrôleur d'interruptions 4 qui est sous sa commande.

Pour fixer les idées, et sans que cela soit limitatif en quoi que ce soit de la portée de l'invention, on va maintenant détailler un exemple pratique d'implémentation possible du procédé de reconfiguration dynamique "à chaud" qui vient d'être décrit, dans le cas d'une architecture du multiprocesseur symétrique dite "MPC", et dans un environnement de système d'exploitation "UNIX" (marque déposée) ou similaire.

Dans un premier temps, sur détection de la défaillance d'un des processeurs (ou plus précisément lorsqu'un processeur est déclaré défaillant de la manière précédemment décrite), on va exécuter une première commande, ou instruction, dite de "gel du système". Cette commande peut avoir la configuration d'une instruction d'interruption, comme indiqué ci-dessous lnt freeze_sytem(int(*m fun)(), cpu <I>t</I> cpu, uint time <I>out,</I> void *arg) <I>(1),</I> instruction dans laquelle "freeze sytem" est le nom donné à celle-ci, " m fun <I>"</I> un pointeur sur une fonction invoquée lorsque le système est effectivement "gelé", ce avant l'expiration d'un délai prédéterminé "time <I>out',</I> "cpu" représente le numéro logique du processeur auquel s'attache la commande "freeze sytem", "time <I>out'</I> le délai précité (généralement en millisecondes) pour l'obtention d'une mutuelle exclusion, et "arg" est un argument représentant une structure de données qui sera passée à la fonction "(m fun)()".

Lorsque le système est effectivement "gelé", la fonction "m fun" s'exécute sur un processeur par l'argument "cpu". Si le délai "time <I>out'</I> expire, cela signifie que la commande "freeze sytem" <I>a</I> échoué. Le système est alors libéré inconditionnellement. Cette commande assure - la préemption et la sauvegarde des contextes des processus (ou "threads") exécutant des tâches assurant le bon fonctionnement du système ; - le blocage des interruptions aux sources d'interruptions, c'est-à-dire les contrôleurs d'interruptions ; - le blocage des requêtes d'horloge, et - le blocage du mécanisme dit des "MPC" ("MultiProcessors Interrupts" ou interruptions multiprocesseurs).

Toutes les interruptions en attente sont exécutées. Le système est dit se trouver dans un "état cohérent". Toutes les tâches commencées sont terminées correctement.

Le système est dit "gelé". La fonction "m fun" passée en argument à la commande "freeze sytem()" va alors pouvoir prendre le relais et exécuter la tâche qui lui incombe, sous protection. Cette tâche sera dédiée, par exemple à l'allocation l dé-allocation dynamique d'un processeur.

Le processeur particulier qui exécute cette fonction est appelée arbitrairement "freeze master" (pour "processeur maître de gel").

La fonction de "gel du système" précitée, exécutée après l'obtention effective de ce dernier, peut créer d'autres tâches, exécutées également lors du "gel de système". Ces tâches seront appelées "freeze slaves", pour "tâches esclaves". Elles sont exécutées sur les autres processeurs, sous le contrôle du processeur maître ("freeze master") et d'une commande supplémentaire ou instruction qui peut présenter la configuration suivante Void start freeze <I>comma</I> nd(void(*s <I>fun)(),</I> cpu <I>t</I> cpu, void *arg) <I>(2),</I> Instruction dans laquelle "start freeze command" est le nom donné à l'instruction, <I>"s</I> fun" est un pointeur sur une fonction "freeze slave" à exécuter, "cpu" représente le numéro logique du processeur dans lequel s'exécute la fonction <I>"s</I> fun", et "arg" est un pointeur sur une structure de données de type privé. Cette structure de données établit le protocole de communication entre le processeur "freeze master" et le ou les processeurs "freeze slaves", de façon à obtenir la synchronisation précédemment évoquée, ce au travers de la structure privée de données pointée par "arg".

Si le délai "lime <I>out'</I> (voir commande (1)) n'est pas expiré avant la mutuelle exclusion du système, c'est-à-dire le "gel du système", la fonction "freeze masteC a la possibilité de commander à l'un des processeurs "freeze slaves" l'exécution de la fonction<I>"s</I> fun()". Celui-ci peut, à titre d'exemple, modifier des données privées d'un des processeurs du système, y compris de celui dans lequel s'exécute la commande "freeze master".

Un protocole de communication s'instaure entre le processeur "freeze master" et le ou les processeurs "freeze slaves", ou, ce qui revient au même, entre les tâches qui s'exécutent dans ceux-ci.

Quand toutes les commandes de type "freeze slave" sont terminées, le processeur "freeze master" peut également terminer sa tâche. Dès cet instant, le "gel" du système peut être levé et le système peut reprendre son fonctionnement normal.

A la lecture de ce qui précède, on constate aisément que l'invention atteint bien les buts qu'elle s'est fixés.

Le procédé de reconfiguration dynamique, à chaud, selon l'invention ne nécessite aucune redondance en matériel. L'architecture matérielle et logique du système reste inchangée. II est seulement nécessaire que le système dispose de moyens de détection d'erreur, soit matériels, soit logiciels, ce qui est prévu par la plupart des systèmes de traitement de l'information. Seul le système d'exploitation nécessite d'être modifié pour supporter un nombre restreint d'instructions spécifiques et ce qui a été appelé "jobs spécifiques".

II doit être clair cependant que l'invention n'est pas limitée aux seuls exemples de réalisations explicitement décrits, notamment en relation avec les figures 1 à 5.

En particulier, les valeurs numériques, par exemple le nombre de processeurs, n'ont été précisées que pour fixer les idées. Elles dépendent essentiellement de l'application précise visée.

II doit être clair aussi que, bien que particulièrement adaptée à un système multiprocesseur symétrique dit "MPC", sous environnement "UNIR", on ne saurait cantonner l'invention à ce seul type d'application. Enfin, bien que le procédé ait été décrit de façon détaillée dans le cas d'un processeur défaillant détecté, le procédé selon l'invention, comme il a été précédemment indiqué, n'est en aucun cas limité à cette application particulière. En outre, les composants défaillants, dans le sens donné à ce terme, peuvent être de nature matérielle ou logicielle. Le procédé selon l'invention n'est pas non plus limité à un seul composant défaillant.

Le nombre de tâches spécifiques lancées dépend de la nature du ou des composants déclarés défaillant. Dans le cas d'un ou plusieurs processeurs d'un système SMP déclarés défaillants, cas qui a fait l'objet d'une description détaillée, à titre d'exemple non limitatif, on exécute une tâche spécifique par processeur, sous la supervision d'une des tâches, dite maître. Pour d'autres types de composants, matériels ou logiciels, il peut être suffisant d'exécuter une seule et unique tâche spécifique. Dans ce dernier cas, le problème du synchronisme de l'exécution des tâches ne se pose pas.

Le procédé selon l'invention peut trouver application dans des architectures de systèmes de traitement de l'information très diverses. Les conditions minimales à remplir sont en nombre limité. II est notamment nécessaire de pouvoir contrôler les sources d'interruptions et de pouvoir stopper les tâches de façon cohérente, ce que permettent la majorité des systèmes informatiques.

Claims (10)

<U>REVENDICATIONS</U>

1. Procédé de reconfiguration d'un système de traitement de l'information comprenant des composants formant des ressources matérielles et logicielles, et fonctionnant sous la commande d'un système d'exploitation déterminé, dans lequel s'exécute au moins une application dite d'utilisateur, caractérisé en ce qu'il comprend au moins les étapes suivantes - une étape préliminaire (60) consistant à détecter (2) un risque préétabli de défaillance sur au moins un desdits composants (CPU3) ; - une première étape (61) consistant, après ladite détection de risque de défaillance, à lancer au moins un programme spécifique pour l'exécution d'une tâche spécifique (J1-J4), sous la commande dudit système d'exploitation (3), en mode non préemptif, de manière à amener ledit système de traitement de l'information (1) à un état prédéterminé cohérent dit "gelé", dans lequel chacune desdites applications d'utilisateur (6) en cours d'exécution est stoppée de façon ordonnée et aucune autre application autorisée à s'exécuter ; - une deuxième étape (62) consistant à exécuter ladite tâche spécifique (J1-J4) pour reconfigurer ledit système de traitement de l'information (1) en effectuant des opérations de ré-allocation et/ou dé-allocation de tout ou partie desdits composants (CPU1-CPU4) de ce système, de manière à préparer l'isolation de chacun (CPU3) desdits composants pour lequel ledit risque préétabli de défaillance a été détecté ; - une troisième étape consistant à isoler chacun (CPU3) desdits composants pour lequel ledit risque de défaillance a été détecté, de manière à ce qu'il ne soit plus reconnu par ledit système de traitement de l'information (1) et ne constitue plus l'une desdites ressources ; et - une étape finale (64) de libération dudit système de traitement de l'information (1) autorisant de nouveau son fonctionnement et l'exécution d'au moins une desdites applications d'utilisateur (6).

2. Procédé selon la revendication 1, caractérisé en ce que ledit composant (CPU3) pour lequel ledit risque de défaillance a été détecté est un composant matériel.

3. Procédé selon la revendication 1, caractérisé en ce que ledit composant pour lequel ledit risque de défaillance a été détecté est un composant logiciel.

4. Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce que ladite deuxième étape comprend le lancement de plusieurs tâches spécifiques (J1-J4), associées chacune à un composant dudit système (CPU1- CPU4), et en ce qu'une desdites tâches spécifiques est désignée comme tâche dite maître, de manière à synchroniser les autres tâches spécifiques, celles-ci étant dites esclaves

5. Procédé selon la revendication 4, caractérisé en ce que ledit système étant un système multiprocesseur (1) comprenant n processeurs (CPU1-CPU4), ledit composant matériel pour lequel ledit risque de défaillance a été détecté est l'un (CPU3) desdits processeurs

6. Procédé selon la revendication 5, caractérisé en ce que ledit système multiprocesseur (1) comprenant un organe de mémoire avec une structure de données de type dit privé en mode partageable, ladite synchronisation des tâches spécifiques est obtenue par un protocole de communication, au travers de ladite structure de données partagées.

7. Procédé selon l'une quelconque des revendications 4 à 6, caractérisé en ce que, ledit système de traitement de l'information (1) comprenant des sources d'interruptions externes et au moins un contrôleur (4) desdites interruptions, il comprend au moins des étapes supplémentaires consistant à exécuter des interruptions en cours, avant d'amener ledit système de traitement de l'information (1) audit état "gelé", et à agir sur chacun desdits contrôleurs d'interruptions (4), de manière à interdire la transmission interruptions, aux dits processeurs (CPU1-CPU4), d'interruptions subséquentes et leur prise en compte avant ladite étape finale (64) de libération du système de traitement de l'information.

8. Procédé selon l'une quelconque des revendications 4 à 6, caractérisé en ce que, ledit système de traitement de l'information comprenant au moins une file d'attente (7) enregistrant les tâches à exécuter dans un plusieurs desdits processeurs (CPU1-CPU4), il comprend au moins des étapes supplémentaires consistant à exécuter les tâches enregistrées dans chacune de ces files d'attentes (7) avant d'amener ledit système de traitement de l'information (1) audit état "gelé" et à bloquer (8) l'enregistrement de tâches subséquentes avant ladite étape finale (64) de libération du système de traitement de l'information (1).

9. Procédé selon l'une quelconque des revendications 1 à 8, caractérisé en ce qu'il comprend des étapes supplémentaires consistant en la génération d'un signal représentant un intervalle de temps maximum prédéterminé, la mesure du temps s'écoulant à partir de ladite première étape (61) et la comparaison continue dudit temps écoulé avec ledit intervalle de temps maximum prédéterminé, de manière à libérer inconditionnellement ledit système de traitement de l'information (1) si ledit temps écoulé devient supérieur audit intervalle de temps maximum prédéterminé.

10. Procédé selon l'une quelconque des revendications 1 à 9, caractérisé en ce que ladite étape préliminaire consiste à surveiller l'évolution de paramètres prédéterminés associés à chacun desdits composants (CPU1-CPU4) dudit système de traitement de l'information (1) et à détecter le franchissement de valeurs de seuils prédéterminés, lesdits dépassements indiquant ledit risque préétabli de défaillance et déclenchant ladite première étape (61).