FR2873464A1 - Architecture de composants logiciels a haute disponibilite, a haute performance - Google Patents
Architecture de composants logiciels a haute disponibilite, a haute performance Download PDFInfo
- Publication number
- FR2873464A1 FR2873464A1 FR0408191A FR0408191A FR2873464A1 FR 2873464 A1 FR2873464 A1 FR 2873464A1 FR 0408191 A FR0408191 A FR 0408191A FR 0408191 A FR0408191 A FR 0408191A FR 2873464 A1 FR2873464 A1 FR 2873464A1
- Authority
- FR
- France
- Prior art keywords
- configuration
- component
- client
- primary
- architecture
- 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.)
- Granted
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/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/2023—Failover techniques
- G06F11/2028—Failover techniques eliminating a faulty processor or activating a spare
-
- 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/2035—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 without idle spare hardware
-
- 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
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Hardware Redundancy (AREA)
Abstract
La présente invention concerne une architecture de composants logiciels à haute disponibilité et à haute performance.L'architecture comporte une configuration primaire (21) et au moins une configuration secondaire (22) pour se substituer à la configuration primaire en cas de défaillance de cette dernière, la configuration primaire (21) comportant au moins un composant de traitement de tâches (28) et un premier composant client (231) et la configuration secondaire (22) comportant au moins un composant de traitement de tâches (28') et un composant client (232), les données d'état (29, 29') étant présentes dans les deux configurations (21, 22), les services d'accès en écriture (26, 26') et en lectures (27, 27') aux composants de traitement des tâches (28, 28') sont séparés de sorte que les requêtes de lecture des données d'état venant des composants clients (231, 232) soient réparties entre les configurations.L'invention s'applique notamment pour des architectures de composants logiciels modulaires par exemple réutilisables, en particulier lorsque ces architectures font partie de systèmes redondants nécessitant une très haute disponibilité.
Description
La présente invention concerne une architecture de composants logiciels à
haute disponibilité et à haute performance. Elle s'applique notamment pour des architectures de composants logiciels modulaires par exemple réutilisables, en particulier lorsque ces architectures font partie de systèmes
redondants nécessitant une très haute disponibilité.
En règle générale, la commande ou gestion des systèmes est assurée par des moyens informatiques à base de calculateurs, de périphériques et d'interfaces adaptés, tous ces composants matériels étant couplés en 1 o réseau. La disponibilité des systèmes en fonctionnement est un point particulièrement sensible. Selon la nature des systèmes, la disponibilité de fonctionnement est plus ou moins capitale.
La disponibilité des systèmes peut donc être très critique. Elle influe notamment la fiabilité des systèmes mais aussi leur rentabilité par exemple.
Pour assurer cette disponibilité de fonctionnement il est connu de dupliquer des chaînes de composants matériels et logiciels, voire de les tripler. C'est ce que l'on appelle la redondance. Ainsi en parallèle de la chaîne principale, encore appelée dispositif maître, est disposée au moins une chaîne redondante, ou dispositif esclave. En cas d'arrêt du dispositif maître c'est le dispositif esclave qui doit prendre en charge la suite de la commande du système et donc assurer la continuité de fonctionnement. En pratique, selon la complexité des systèmes, une chaîne comporte un à plusieurs calculateurs et les périphériques associés.
Deux critères au moins sont à considérer pour apprécier la performance d'un système redondant, ou plus précisément pour apprécier la performance de disponibilité d'un système. En premier lieu l'intégrité des données et des fonctions est à prendre en compte. L'autre critère important est le temps de réponse du dispositif esclave suite à l'arrêt du dispositif maître. Il existe des systèmes dont les arrêts de fonctionnement ne doivent être extrêmement court voire inexistant, ce qui implique par exemple que l'arrêt de fonctionnement au niveau des calculateurs soit d'une durée nettement inférieur à une seconde, de l'ordre de 500 millisecondes.
Par ailleurs l'architecture logicielle des systèmes modernes est généralement basée sur une approche composants, en particulier pour des systèmes modulaires et réutilisables. Ces deux dernières propriétés sont très importantes pour du point de vue industriel et économique. Il existe des modèles de composants logiciels standards, par exemple EJB, sigle de l'expression anglo-saxonne Enterprise Java Bean ou CCM, sigle de l'expression anglo-saxonne CORBA Component Model , qui supportent une architecture basée sur l'approche composants. Cependant ces modèles de composants logiciels ne permettent pas de répondre à une contrainte de haute disponibilité haute performance. Il existe par exemple un modèle, FT CORBA, qui répond aux contraintes de disponibilité mais il s'agit d'un modèle orienté objets et non orienté composants logiciels donc bas niveau. Ce modèle s'adresse à CORBA objets, FT signifiant Fault Tolerance qui est l'expression anglo-saxonne qui exprime la disponibilité.
Un but de l'invention est notamment de permettre la réalisation d'une architecture logicielle à haute disponibilité et haute performance, cette architecture étant orientée composants logicielles. A cet effet, l'invention a pour objet une architecture de composants logiciels comportant une configuration primaire et au moins une configuration secondaire pour se substituer à la configuration primaire en cas de défaillance de cette dernière, la configuration primaire comportant au moins un composant de traitement de tâches et un premier composant client et la configuration secondaire comportant au moins un composant de traitement de tâches et un composant client, les données d'état étant présentes dans les deux configurations. Les services d'accès en écriture et en lectures aux composants de traitement des tâches sont séparés de sorte que les requêtes de lecture des données d'état venant des composants clients soient réparties entre les configurations.
Dans un mode de réalisation, le premier composant client accède en lecture des données d'état à l'intérieur de la configuration primaire et un composant client d'une configuration secondaire accède en lecture aux données d'état à l'intérieur de sa configuration. La configuration primaire répond aux requêtes en écriture de tous les composants clients.
La détection d'une défaillance de la configuration primaire est par exemple effectuée par un modèle orienté objet testant, lors de chaque requête lancée par un composant client la réponse du composant de traitement de tâches. Le modèle utilisé est le modèle FT CORBA.
Un service de distribution des données permet de dupliquer les données d'état d'une configuration à l'autre. Chaque configuration est par exemple implantée dans un calculateur distinct. Les configurations peuvent être reliées entre elles par une liaison multicast, les accès d'une configuration à l'autre s'effectuant par cette liaison.
L'invention a pour principaux avantages qu'elle s'applique pour la gestion de tous types de systèmes, qu'elle s'appuie sur des infrastructures bas niveau existantes, qu'elle s'adapte à de nombreux types de configurations logicielles, qu'elle s'adapte à des architectures modulaires et réutilisable, qu'elle est économique et qu'elle est simple à mettre en oeuvre.
D'autres caractéristiques et avantages de l'invention apparaîtront à l'aide de la description qui suit faite en regard de dessins annexés qui représentent: la figure 1, un exemple de réalisation informatique redondant classique; la figure 2, un exemple d'architecture de composants logiciels selon l'invention; la figure 3, par une vue partielle un autre exemple de réalisation d'une 25 architecture selon l'invention; la figure 4, un état de fonctionnement en cas de défaillance de la partie primaire de l'architecture; la figure 5, une illustration d'un mécanisme bas niveau détectant notamment les défaillances des composants logiciels.
La figure 1 représente un exemple de réalisation d'un système informatique redondant classique. Ce système comporte des composants matériels dans lesquels sont implantés des composants logiciels. Il comporte une voie maître 1 et une voie esclave 2, cette dernière étant une réplication de la voie maître. Pour simplifier la présentation chaque voie comporte un seul calculateur. Un poste client 3 est relié aux deux calculateurs 1, 2. Les échanges de données entre le poste client et les calculateurs se font par liaison multicast. D'autres postes clients pourraient adresser les calculateurs. Chaque calculateur comporte des composants logiciels 4, 5. Des composants d'accès en écriture/écriture 6, 8 et les interfaces correspondantes permettent les échanges entre les composants logiciels et le client 3.
Il existe au moins deux styles de fonctionnement d'un tel système redondant, un style actif et un style passif. Dans le styles actif les différents composants 4, 5 de chacune des deux voies 1, 2 exécutent en parallèle les mêmes instructions. Néanmoins une seule voie, la voie maître, répond aux requêtes du client 3.
Dans le style passif seul les composants de la voie maître 1 exécutent le traitement. Elle reçoit les requêtes du poste client et fait le traitement. Les composants de la voie esclave 2 n'effectuent pas de traitement. Ils restent inactifs, à l'état de veille.
Comme il a été indiqué précédemment, un modèle orienté objet tel que par exemple FT CORBA qui pourrait répondre aux exigences de disponibilité, au niveau performance ne peut pas traiter les composants logiciels 4, 5 du système.
La figure 2 présente un exemple de réalisation d'une architecture de composants logiciels selon l'invention. Pour assurer la disponibilité de service le système comporte deux configurations, une configuration primaire 21 et une configuration secondaire 22, appelé par la suite configuration back up . Chaque configuration est par exemple implantée dans un calculateur. Les deux calculateurs sont par exemple reliés entre eux par une liaison multicast. La configuration maître 21 comporte au moins un composant client 231 et des composants logiciels 24, 25, 26, 27, 28. Un 3o composant logiciel 28 exécute les traitements. Des composants logiciels d'accès aux services 24, 25, 26, 27 relient le client 23 au composant logiciel de traitement 28. Ce composant logiciel 28 de traitement de tâches est le composant dont la disponibilité est requise. Il sera appelé par la suite composant FT en référence aux initiales anglosaxonnes Fault Tolerance . Un composant 29 comporte l'état du système, cet état étant constitué de l'ensemble des données. Cet état évolue bien sûr au cours du temps. Il pourrait être logé ailleurs que dans le composant logiciel de traitement. Le composant d'état 29 peut être intégré dans le composant FT 28.
La configuration back up 22 comporte une réplication 28' du composant FT 28 de la configuration primaire 21. Ce composant FT 28' est prévu pour exécuter les traitements effectués par le composant 28 de la configuration primaire en cas de défaillance de celui-ci. Un composant 29' est aussi destiné à recueillir l'état du système. Cette configuration back up 22 comporte aussi un composant client 232 qui n'est pas nécessairement une réplication du client 231 de la configuration primaire, du moins en ce qui concerne ses fonctions dans le système global. II s'agit en fait d'un autre client. Ce dernier aurait pû être situé dans la configuration primaire ou dans une autre configuration. Néanmoins pour des raisons de standardisation des configurations le deuxième client est placé dans la configuration back up. II est par exemple relié au composant FT 28' par les réplications 24', 25', 26', 27' des composants d'accès aux services 24, 25, 26, 27 de la configuration primaire, de sorte que l'architecture logicielle de la configuration back up est une réplication de l'architecture logicielle de la configuration primaire. En cas de défaillance de la configuration primaire, notammente de son composant FT 28, la configuration back up est destinée à prendre le relai par l'intermédiaire de son composant FT 28'. Les deux configurations sont par exemple hébergées chacune dans un calculateur distinct.
Selon l'invention le composant d'état 29 de la configuration primaire et le composant d'état 29' de la configuration back up comportent en permanence l'état du système, c'est-à-dire les données décrivant cet état. En fait il s'agit de toutes les données en jeu à un instant donné de reconstituer l'état du système. Donc les données décrivant l'état du système ne sont pas seulemen présentes dans la configuration primaire mais aussi dans la configuration back up. Un service de distribution de données 30 permet de dupliquer les données du composant d'état 29 de la configuration primaire 21 dans le composant d'état 29' de la configuration back up 22 et vice versa. Ce service de distribution est par exemple implanté dans la configuration primaire 21 mais pas nécessairement. La distribution est symbolisée par une ligne sur la figure 2, il s'agit d'une liaison fonctionnelle et non matérielle spécifique car les échanges entre les deux configurations se font par une liaison matérielle unique qui est une liaison multicast. D'autres types de liaisons pourraient bien sûr être envisagées, y compris des liaisons spécifiques.
Les accès de service au composant FT 28 de la configuration primaire se font par deux accès séparés, un accès dédié à l'écriture 26 et un accès dédié à la lecture 27. Une interface logicielle 24 est associée au service d'accès en écriture 26 et une autre interface logicielle 25 est associée au service d'accès en lecture 27. Ces interfaces 24, 25 sont adaptés au client 231 en particulier pour lui permettre d'accéder à chacun des services 26, 27, en écriture et en lecture.
De même, et en particulier conformément à la réplication de l'architecture logicielle de la configuration primaire, l'accès au service du composant FT 28' de la configuration back up est séparé en deux, avec un accès en écriture 26' et un accès en lecture 27'. L'accès en écriture 26' est non pas couplé au composant FT 28' de la configuration back up mais au composant FT 28 de la configuration primaire, de sorte que le deuxième client accède en écriture à ce composant FT 28 de la configuration primaire. Les interfaces logicielles 24', 25' autorisent l'accès aux services 26', 27' pour le deuxième client 232. Les liaisons de services entre les deux configurations se font par exemple par liasion multicast.
Le composant FT 28 de la configuration primaire 21 et le composant FT 28' de la configuration back up fonctionnent en parallèle, c'est-à-dire selon le style actif précédemment décrit. Les accès aux services des composants FT 28, 28', quant à eux ne fonctionnent pas en parallèle. En particulier, le composant FT 28 de la configuration primaire fonctionne en écriture/lecture et le composant FT 28' de la configuration back up fonctionne en lecture seule. De la sorte le composant FT 28 de la configuration primaire répond aux requêtes du premier client 231 et du deuxième client 232. Le premier client 231 lit les données sur ce composant FT 28. Quant au deuxième client 232, il lit les données sur le composant FT 28'. Ce mode de fonctionnement est possible car les données sont présentes dans les deux configurations.
Ainsi les services fournis par un composant FT sont séparés d'une part en services en écriture et d'autre part en services en lecture. Les services en écriture altèrent l'état du composant FT et requèrent des ressources de gestion. Dans l'exemple de réalisation de la figure 2, seul le composant FT 28 de la configuration primaire répond aux accès en écriture. L'accès en lecture n'altère pas l'état du composant. Les deux composants 28, 28' peuvent donc répondre aux accès de service en lecture, d'autant plus que l'état du système est répliqué dans chacun des composants, du moins dans les composants d'état 29, 29'. Les accès en lecture peuvent impliquer des traitements complexes et inclure des notifications de services à critères de sélection.
Une architecture d'un système selon l'invention telle que présentée par la figure 1 permet d'améliorer les perfomances en particulier au niveau de la disponibilité. Les requêtes en lecture et en écriture du premier client 231 sont traitées par le composant FT 28 de la configuration primaire 21. Seules les requêtes en écriture du deuxième client 232 sont traitées par ce composant FT 28. Les requêtes en lecture de ce deuxième client 232 sont traitées directement par le composant FT 28 de la configuration back up 22. Ainsi la charge globale est répartie entre la partie primaire et la partie back up. II en résulte une amélioration de performance.
La figure 3 illustre par une vue partielle une variante de réalisation. La figure 2 a montré que la séparation des accès en écriture des accès en lecture permettait de répartir les requêtes de lectures entre les différentes configurations. La figure 2 présente un exemple de répartition possible des accès en lecture. D'autres exemples sont possible. Dans la variante de réalisation de la figure 3, le premier client 232 accède aussi en lecture au composant FT 28' de la configuration back up. En particulier le service d'accès en écriture 27 de la configuration primaire est connecté au composant FT 28' de la configuration back up. La partie primaire ne fonctionne ainsi qu'en accès en écriture et la partie back up ne fonctionne qu'en accès en lecture, ce qui va vers une meilleure répartition de la charge.
Néanmoins ce gain peut être anhilé ou du moins fortement réduit du fait que la liaison au composant FT 28' de la configuration back up depuis l'accès au service d'écriture 27 de la configuration primaire se fait via le réseau multicast 31. En effet dans l'exemple de réalisation de la figure 2 chaque configuration, client compris, est implantée sur un même calculateur ou du moins sur un même système matériel, ce qui simplifie les liaisons entre composants. Le passage à un autre calculateur ou à une autre structure matériel nécessite le passage par la liaison multicast avec notamment tous les protocoles associés.
La figure 4 illustre un cas de défaillance de la configuration primaire 21 où le traitement est repris par la configuration back up 22. Plus précisément la figure 4 présente un cas où le composant FT 28 de la configuration primaire 21 est hors service. C'est le composant FT 28' de la configuration back up qui supporte alors toute la charge et qui assure notamment tous les services en écriture et en lecture. En particulier les deux accès en écriture 26, 26' qui étaient connectés au composant FT 28 de la partie primaire sont connectés au composant FT 28' de la partie back up. L'accès en écriture 27 de la partie primaire est maintenant connecté à ce composant FT 28'. Les autres connexions restent inchangées. L'amélioration de la répartion de la charge entre les configurations primaire et back up, ainsi que le fait que l'état du système soit stocké à la fois dans la configuration primaire et dans la configuration back up concourrent ensemble à l'amélioration des performances dans la mesure où dès défaillance de la configuration primaire la configuration back up peut très vite reprendre le relai. Il est ainsi possible d'espérer selon les cas de parvenir une indisponibilité de service inférieure à 500 millisecondes. C'est-à-dire que la durée entre l'apparition de la défaillance de la configuration primaire et la reprise en main par la configuration back up peut être inférieure à 500 millisecondes.
Pour arriver dans le nouvel état illustré par la figure 4 où la configuration back up a pris le rôle de la configuration primaire défaillante, il faut des moyens pour détecter la défaillance de la configuration primaire et pour élire une nouvelle configuration primaire. Dans le cas de l'exemple des figures 3 et 4 où il n'y a que deux configuration, le choix se reporte sur l'unique configuration disponible. Il faut aussi des moyens pour dérouter les requêtes des clients, en l'occurrence le premier client dans le cas des figures 3 et 4, vers la nouvelle configuration primaire. En particulier il faut dérouter les services d'accès en écriture et lecture connectés au composant FT 28 de la configuration primaire vers le composant FT 28' de la configuration back up.
Pour y parvenir le système selon l'invention utilise une structure bas niveau qui traite les objets logiciels. Le modèle orienté objet utilisé est par exemple le modèle FT CORBA.
La figure 5 illustre un exemple d'infrastructure bas niveau qui permet de répondre aux exigences précitées, en particulier pour la détection des défaillances et pour dérouter les requêtes. Le modèle FT CORBA répond au mécanismes illustré. D'autres types de modèles qui répondent à ce mécanisme ou à des mécanismes analogues pourraient être utilisés. La figure 5 illustre donc une infrastructure logicielle bas niveau. Le client 231 dialogue avec un objet logiciel 51 qui contient une référence. De façon général un client a besoin d'une référence pour communiquer. L'objet logiciel comporte en fait au moins deux références, la référence du code d'une copie primaire 52, destinée à un test de conformité, contenue dans la configuration primaire 21 et la référence du code d'une copie secondaire 53 comprise dans la configuration back up 22. Lorsque le client lance une communication, pour une requête en lecture ou en écriture, il teste en premier la copie primaire. Si cette dernière est conforme à la référence, cela signifie que le composant FT 28 de la configuration primaire est en service. Si le test est négatif, cela signifie que le composant FT 28 ne répond plus et donc qu'il est en service, le modèle FT CORBA par exemple déroute la même requête vers la copie secondaire. Puis déroute toutes les services d'accès vers le composant FT 28' de la configuration secondaire. Le modèle FT CORBA est particulièrement bien adapté car il comporte dans ses protocoles d'accès un test de référence. Sachant détecter les composants défaillants le modèle peut ensuite orienter les accès vers les composants en service.
Les exemples de réalisation d'architectures présentés précédemment ne comportent que deux configurations 21, 22. L'invention s'applique évidemment à des systèmes comportant un nombre supérieur de réplications. On peut par exemple envisager N réplications de la configuration primaire 21. Dans ce cas la partie primaire 21 répond aux requêtes en écriture de tous les clients. Le premier composant client 231 accède en lecture des données d'état à l'intérieur de la configuration primaire 21 et un composant client 232 d'une configuration secondaire 22 accède en lecture aux données d'état à l'intérieur de sa configuration 22. En cas de défaillance de la configuration primaire, une configuration secondaire prend en charge les traitements assurés par cette dernière et devient à son tour configuration primaire. Dans un autre exemple de réalisation, la configuration primaire, et ses réplications, peuvent comporter plusieurs clients.
En particulier l'invention est bien adapté à une architecture globale modulaire et réutilisable. En effet les différentes configuration et leurs réplications peuvent constituer des modules réutilisables. A ce titre, outre l'aspect modulaire et réutilisable, l'invention est aussi économique.
Avantageusement l'invention s'applique pour la gestion de tous types de systèmes, en particulier pour de gros systèmes dont la sureté de fonctionnement exige une haute disponibilité et une haute performance de leurs systèmes de commande ou de gestion. Par ailleurs l'invention est simple à mettre en oeuvre, elle ne nécessite notamment pas de composants supplémentaires ni de connexions complexes. Elle s'appuie sur des infrastructures bas niveau existantes et elle s'adapte à de nombreux types de configurations logicielles, ce qui lui permet un large spectre d'applications.
Claims (8)
1. Architecture de composants logiciels comportant une configuration primaire (21) et au moins une configuration secondaire (22) pour se substituer à la configuration primaire en cas de défaillance de cette dernière, caractérisée en ce que la configuration primaire (21) comportant au moins un composant de traitement de tâches (28) et un premier composant client (231) et la configuration secondaire (22) comportant au moins un composant de traitement de tâches (28') et un composant client (232), les données d'état (29, 29') étant présentes dans les deux configurations (21, 22), les services d'accès en écriture (26, 26') et en lectures (27, 27') aux composants de traitement des tâches (28, 28') sont séparés de sorte que les requêtes de lecture des données d'état venant des composants clients (231, 232) soient réparties entre les configurations.
2. Architecture selon la revendication 1, caractérisée en ce que le premier composant client (231) accède en lecture des données d'état à l'intérieur de la configuration primaire (21) et un composant client (232) d'une configuration secondaire (22) accède en lecture aux données d'état à l'intérieur de sa configuration (22).
3. Architecture selon l'une quelconque des revendications précédentes, caractérisé en ce que la configuration primaire (21) réponds aux requêtes en écriture de tous les composants clients (231, 232).
4. Architecture selon l'une quelconque des revendications précédentes, caractérisée en ce que la détection d'une défaillance de la configuration primaire (21) est effectuée par un modèle orienté objet testant, lors de chaque requête lancée par un composant client (231, 232) la réponse du composant de traitement de tâches (28).
5. Architecture selon la revendication 4, caractérisée en ce que le modèle est le modèle FT CORBA.
6. Architecture selon l'une quelconque des revendications précédentes, caractérisée en ce qu'elle comporte un service (30) de distribution des données pour dupliquer les données d'état (29, 29') d'une configuration à l'autre.
7. Architecture selon l'une quelconque des revendications précédentes, 5 caractérisée en ce que chaque configuration (21, 22) est implantée dans un calculateur distinct.
8. Architecture selon l'une quelconque des revendications précédentes, caractérisée en ce que les configurations (21, 22) sont reliées entre elles par o une liaison multicast, les accès d'une configuration à l'autre s'effectuant par cette liaison.
Priority Applications (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0408191A FR2873464B1 (fr) | 2004-07-23 | 2004-07-23 | Architecture de composants logiciels a haute disponibilite, a haute performance |
| US11/572,567 US7587632B2 (en) | 2004-07-23 | 2005-07-19 | High availability, high performance software component architecture |
| PCT/EP2005/053480 WO2006010726A1 (fr) | 2004-07-23 | 2005-07-19 | Architecture de composants logiciels a haute disponibilite, a haute performance |
| EP05764043A EP1774436A1 (fr) | 2004-07-23 | 2005-07-19 | Architecture de composants logiciels a haute disponibilite, a haute performance |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0408191A FR2873464B1 (fr) | 2004-07-23 | 2004-07-23 | Architecture de composants logiciels a haute disponibilite, a haute performance |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR2873464A1 true FR2873464A1 (fr) | 2006-01-27 |
| FR2873464B1 FR2873464B1 (fr) | 2006-09-29 |
Family
ID=34948237
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR0408191A Expired - Fee Related FR2873464B1 (fr) | 2004-07-23 | 2004-07-23 | Architecture de composants logiciels a haute disponibilite, a haute performance |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US7587632B2 (fr) |
| EP (1) | EP1774436A1 (fr) |
| FR (1) | FR2873464B1 (fr) |
| WO (1) | WO2006010726A1 (fr) |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5799323A (en) * | 1995-01-24 | 1998-08-25 | Tandem Computers, Inc. | Remote duplicate databased facility with triple contingency protection |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5978565A (en) * | 1993-07-20 | 1999-11-02 | Vinca Corporation | Method for rapid recovery from a network file server failure including method for operating co-standby servers |
| US5774668A (en) * | 1995-06-07 | 1998-06-30 | Microsoft Corporation | System for on-line service in which gateway computer uses service map which includes loading condition of servers broadcasted by application servers for load balancing |
| US5802265A (en) * | 1995-12-01 | 1998-09-01 | Stratus Computer, Inc. | Transparent fault tolerant computer system |
| US6260158B1 (en) * | 1998-05-11 | 2001-07-10 | Compaq Computer Corporation | System and method for fail-over data transport |
| GB2353113B (en) * | 1999-08-11 | 2001-10-10 | Sun Microsystems Inc | Software fault tolerant computer system |
| US6947434B2 (en) * | 2000-11-16 | 2005-09-20 | Telefonaktiebolaget Lm Ericsson (Publ) | Subgroup multicasting in a communications network |
-
2004
- 2004-07-23 FR FR0408191A patent/FR2873464B1/fr not_active Expired - Fee Related
-
2005
- 2005-07-19 US US11/572,567 patent/US7587632B2/en not_active Expired - Fee Related
- 2005-07-19 EP EP05764043A patent/EP1774436A1/fr not_active Withdrawn
- 2005-07-19 WO PCT/EP2005/053480 patent/WO2006010726A1/fr active Application Filing
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5799323A (en) * | 1995-01-24 | 1998-08-25 | Tandem Computers, Inc. | Remote duplicate databased facility with triple contingency protection |
Non-Patent Citations (2)
| Title |
|---|
| P. FELBER, P. NARASIMHAN: "Experiences, Strategies, and Challenges in Building Fault-Tolerant CORBA Systems", IEEE TRANSACTIONS ON COMPUTERS, vol. 53, no. 5, May 2004 (2004-05-01), pages 497 - 511, XP002312917 * |
| SOLID.: "Solid FlowEngine for Smart Networks - A Solid White Paper", INTERNET, 2002, XP002312916, Retrieved from the Internet <URL:http://www.dmreview.com/whitepaper/WID432.pdf> [retrieved on 20050104] * |
Also Published As
| Publication number | Publication date |
|---|---|
| US20080141248A1 (en) | 2008-06-12 |
| US7587632B2 (en) | 2009-09-08 |
| EP1774436A1 (fr) | 2007-04-18 |
| FR2873464B1 (fr) | 2006-09-29 |
| WO2006010726A1 (fr) | 2006-02-02 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10891209B1 (en) | System and method for statistical application-agnostic fault detection | |
| US6530039B1 (en) | Porting engine for testing of multi-lingual software | |
| USRE42685E1 (en) | Upgrading digital media servers | |
| US6671699B1 (en) | Shared database usage in network devices | |
| US20060020858A1 (en) | Method and system for minimizing loss in a computer application | |
| US7954104B2 (en) | Remote copy storage device system and a remote copy method to prevent overload of communication lines in system using a plurality of remote storage sites | |
| US10817364B1 (en) | System and method for statistical application agnostic fault detection | |
| US20050262411A1 (en) | Migration method for software application in a multi-computing architecture, method for carrying out functional continuity implementing said migration method and multi-computing system provided therewith | |
| FR2794876A1 (fr) | Procede de reconfiguration d'un systeme de traitement de l'information sur detection de defaillance d'un composant | |
| US20080288812A1 (en) | Cluster system and an error recovery method thereof | |
| EP0889410A2 (fr) | Procédé et appareil pour dispositifs de stockage de données à haute disponibilité et avec cache | |
| US6654903B1 (en) | Vertical fault isolation in a computer system | |
| FR2917200A1 (fr) | Systeme de maintenance pour un ensemble d'equipements | |
| FR2765702A1 (fr) | Architecture de systeme de traitement de l'information | |
| FR2835936A1 (fr) | Procede et systeme d'analyse d'evenements de blocage logiciel | |
| EP1085448A1 (fr) | Système d'administration pour machines multimodulaires multiprocesseurs | |
| FR2873464A1 (fr) | Architecture de composants logiciels a haute disponibilite, a haute performance | |
| EP1865412A1 (fr) | Pilotage d'un dispositif multifonctions | |
| EP0426531B1 (fr) | Système de test d'un microprocesseur | |
| US7325237B2 (en) | System having customization modules to provide customizations | |
| JPH07121395A (ja) | 予備装置優先選択方法 | |
| FR2748136A1 (fr) | Module electronique avec architecture redondante pour controle d'integrite du fonctionnement | |
| EP0599681B1 (fr) | Outil de simulation d'un code de réseau | |
| EP0297964B1 (fr) | Procédé de pilotage d'équipements par l'intermédiaire d'un réseau local, notamment pour l'automatisation d'un atelier | |
| CN118260079A (zh) | 容器资源处理的方法、装置、计算机设备及介质 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLFP | Fee payment |
Year of fee payment: 13 |
|
| PLFP | Fee payment |
Year of fee payment: 14 |
|
| PLFP | Fee payment |
Year of fee payment: 15 |
|
| PLFP | Fee payment |
Year of fee payment: 16 |
|
| ST | Notification of lapse |
Effective date: 20210305 |