SURETE DE FONCTIONEMENT

DES APPLICATIONS EN RESEAUX

• 1. Généralités et définitions
1.1 Attributs de la sûreté de fonctionnement
1.2 Taux de défaillance et temps moyens
1.3 Quelques exemples de domaines d’application
1.4 Entraves à la sûreté de fonctionnement
1.5 Moyens pour la sûreté de fonctionnement

2. Techniques de la tolérance aux fautes

  2.1 La redondance comme principe de base
2.2 Recouvrement d’erreur
2.2.1 Recouvrement d’erreur par reprise
2.2.2 Recouvrement d’erreur par poursuite
2.2.3 Recouvrement d’erreur par compensation
2.3 Tolérance aux fautes de communications
2.3.1 Communications point-à-point
2.3.2 Communications multipoints
2.4 Techniques pour les systèmes répartis
2.4.1 Consensus
2.4.1.1 Consensus avec perte de messages
2.4.1.2 Consensus avec processus défaillants
2.4.2 Diffusion fiable
2.4.3 Protocole d’élection
2.4.4 Protocole d’appartenance à un groupe
2.4.5 Contrôle de l’accès concurrent aux données répliquées
2.4.6 Protocole d’engagement atomique
2.4.7 Synchronisation d’horloges physiques et horloges logiques
2.4.8 Réplication de processus

3. Approches pratiques
3.1 Architectures en grappe
3.1.1 Principales caractéristiques
3.1.2 Architecture Sun Cluster
3.2 Tolérance aux fautes dans CORBA
3.3 RSERPOOL
3.3.1 Profil minimal
3.3.2 Profil complet
 4. Une étude de cas : un routeur Internet
 4.1 Tolérance aux fautes dans un routeur
4.2 Tolérance aux fautes des applications de routage
4.2.1 OSPF , RIP
4.2.2 BGP
4.2.3 Bilan

5. Conclusion
INTRODUCTION
•  Cet article a pour but de présenter la sûreté de fonctionnement des
applications en réseau sous un angle pratique. Nous commençons par
décrire rapidement les concepts de la sûreté de fonctionnement des
systèmes informatiques puis nous nous attachons à l’un des moyens pour
l’obtenir, la tolérance aux fautes, qui reste indispensable pour que le
système continue à fonctionner malgré la présence de fautes n’ayant pu
être ni éliminées ni prévenues. Nous donnons alors un panorama des
techniques pouvant être employées en mettant l’accent sur les
particularités des systèmes répartis montrant la complexité du
développement d’applications en réseau tolérantes aux fautes.

• Les deux dernières parties de l’article illustrent la mise en pratique des

techniques présentées précédemment. Nous mentionnons tout d’abord
les architectures en grappe pour lesquelles les constructeurs
informatiques fournissent de nombreuses solutions clés en main. Puis
nous décrivons la récente norme FT CORBA (Faut-Tolerant Common
Object Request Broker Architecture) de l’OMG (Object Management
Group) recommandée aux éditeurs de logiciels support pour les
applications à base d’objets distribués et nous traitons des récents
travaux de l’IETF (Internet Engineering Task Force) concernant les
applications Internet. Nous terminons par une étude de cas présentant la
fiabilisation d’un routeur Internet.
Tableau de sigles
Sigles Définitions
ASAP Agregate Server Access Protocol
ATM Asynchronous Transfer Mode
BGP Border Gateway Protocol
Common Object Request Broker
CORBA
Architecture
CSMA Carrier Sense Multiple Access
EGP Exterior Gateway Protocol
ENRP Endpoint Name Resolution Protocol
FIFO First In, First Out
Fault-Tolerant Common Object Request
FT CORBA
Brocker Architecture
HTTP HyperText Transfer Protocol
IETF Internet Engineering Task Force
IGP Interior Gateway Protocol
 Interoperable Object Group
IOGR
Reference
IOR Interoperable Object Reference
IP Internet Protocol
IRp Inter-Replica protocol
Intermediate System to Intermediate
IS-IS
System
MTBF Mean Time Between Failure
MTTF Mean Time To Failure
MTTR Mean Time To Repair
MUT Mean Up Time
NFS Network File System
NMR N Modular Redundancy
NTP Network Time Protocol
OMG Object Management Group
ORB Object Request Broker

OSPF Open Shortest Path First

PE Pool Element

PU Pool User

RAID5 Redundant Array of Inexpensive Disks

RIP Routing Information Protocol

RPC Remote Procedure Call

RSERPOOL Reliable Server Pooling

SCTP Stream Control Transmission Protocol

SRM Scalable Reliable Multicasting

TCP Transmission Control Protocol

TMR Triple Modular Redundancy

UDP User Datagram Protocol

• 1. Généralités et définitions

• 1.1 Attributs de la sûreté de fonctionnement

1.2 Taux de défaillance et temps moyens
1.3 Quelques exemples de domaines
d’application
1.4 Entraves à la sûreté de fonctionnement
1.5 Moyens pour la sûreté de
fonctionnement
• Cette première partie présente les différents concepts caractérisant la
sûreté de fonctionnement des systèmes informatiques. Nous nous
attachons à décrire un ensemble de concepts minimal et cohérent
permettant d’appréhender la problématique et de mieux comprendre les
différentes solutions souvent mises en œuvre dans les produits du
marché. Cette partie s’appuie sur l’article  [R 7 595], réf. [41] donnant un
ensemble plus complet de définitions concernant la sûreté de
fonctionnement des systèmes informatiques, et sur l’article  [AG 4 670],
réf. [42] détaillant un large panorama des moyens de la sûreté de
fonctionnement pour maîtriser les risques dans les systèmes industriels.
• Les concepts que nous détaillons dans les prochaines sections peuvent
être organisés sous la forme d’un arbre  (figure 1).

• 1.1 Attributs de la sûreté de fonctionnement

• La sûreté de fonctionnement peut être définie comme étant la capacité
qu’a un système de fournir un service à un utilisateur avec un niveau de
confiance justifié.
• Cette tentative de définition amène deux remarques :
• d’une part, l’utilisateur d’un système et le concepteur d’un système doivent
avoir la même acceptation du service devant être délivré par le système,
cela souligne le rôle essentiel des spécifications ;
• d’autre part, le niveau de confiance que l’on peut placer dans la capacité du
système à délivrer le service doit être justifié et donc justifiable.
• La vie d’un système est perçue par ses utilisateurs comme une alternance
entre deux états du service par rapport à l’accomplissement de la fonction
du système :
• service correct (état de fonctionnement OK) où le service délivré accomplit
la fonction du système ;
• service incorrect (états de dysfonctionnement KO) où le service délivré
n’accomplit pas la fonction du système.
• Une défaillance est donc une transition d’un service correct à un service
incorrect, l’inverse étant une restauration. La quantification de la probabilité
de défaillance permet de définir fiabilité, sécurité- innocuité (relativement à
la non-occurrence de défaillances catastrophiques), disponibilité, et
maintenabilité comme des mesures de la sûreté de fonctionnement.
Figure 1 - L’arbre de la sûreté de fonctionnement
Figure 2 - Fiabilité
Figure 3 - Sécurité-innocuité
• Fiabilité : la fiabilité (reliability en anglais) d’un système est une fonction
du temps R (t ) égale à la probabilité conditionnelle que le système délivre
le service attendu d’un instant initial t 0 jusqu’à l’instant t, sachant que le
service était délivré correctement à t 0 (figure 2). Ainsi, la fiabilité mesure
la continuité de la délivrance d’un service approprié.

• Sécurité-innocuité : la sécurité d’un système est une fonction du temps S

(t ) égale à la probabilité conditionnelle que le système ne présente pas de
comportement défaillant dangereux d’un instant initial t 0 jusqu’à l’instant
t, sachant que l’état du système n’était pas dangereux à t 0 (figure 3).

• Ces définitions montrent que la fiabilité et la sécurité sont des notions

voisines. Les états incorrect (KO) et incorrect suite à une défaillance
dangereuse (KO non sécuritaire) peuvent être regroupés en un méta-état
puits. Le système doit être conçu pour que la probabilité d’entrer dans ce
groupe d’états soit suffisamment faible sur un intervalle [t 0 , T ]
représentant la durée d’utilisation (ou durée de mission) du système.
• La sécurité peut également être considérée par rapport à la préservation
de la confidentialité (non-occurrence de divulgations non autorisées) et
de l’intégrité (non-occurrence d’altérations non autorisées) des
informations. L’ambiguïté introduite en utilisant le même terme de
sécurité pour deux points de vue différents n’existe pas en anglais où
safety est utilisé pour la sécurité au sens des défaillances catastrophiques
et security pour la sécurité au sens de la confidentialité, le terme
dependability caractérisant le concept plus général introduisant la notion
de confiance.
• Disponibilité : la disponibilité (availability ) d’un système est une fonction
du temps A (t ) égale à la probabilité que le système délivre le service à
l’instant t (figure 4).
Figure 4 - Disponibilité
Figure 5 - Maintenabilité
• Maintenabilité : la maintenabilité se définit d’une part comme la facilité avec
laquelle la maintenance d’un système peut être effectuée. Elle est d’autre part
une mesure de l’intervalle de temps jusqu’à restauration depuis la dernière
défaillance survenue, ou, ce qui est équivalent, de la délivrance continue d’un
service incorrect. Elle se caractérise par la probabilité M (t ) qu’a un système
d’être en état, à l’instant t, d’accomplir les fonctions requises sachant qu’il était
en panne à l’instant t 0 (figure 5).

• 1.2 Taux de défaillance et temps moyens

• Les notions de fiabilité et de maintenabilité d’un système ayant été présentées,
les fonctions R (t ) et M (t ) permettent de définir de nouvelles grandeurs.
• Le taux de défaillance, généralement noté λ (t ) est :

• Il représente l’intensité de défaillance en fonction du temps. C’est la probabilité

conditionnelle, divisée par dt, de tomber en panne entre t et t + dt sachant
qu’au temps t l’entité n’est pas défaillante.
• Le taux de restauration, généralement noté µ (t ), se définit de manière analogue
par rapport à la maintenabilité :

•
Le MTTF (Mean Time To Failure ) est la moyenne des durées de fonctionnement
de l’instant 0 à la première défaillance. Cela correspond en français à la moyenne
des temps de bon fonctionnement, mais ne doit pas être confondu avec le MTBF
(Mean Time Between Failure ) qui est la moyenne des temps séparant deux
défaillances consécutives. Pour une entité réparable, connaissant une alternance
de périodes de fonctionnement ininterrompu et de périodes de maintenance, le
MTBF est la moyenne des durées incluant la période de remise en état.
• On appelle MUT (Mean Up Time ) la moyenne des temps de bon fonctionnement.
En général, un système satisfaisant connaît des périodes de panne beaucoup plus
courtes que les périodes de bon fonctionnement ininterrompu ; de ce fait, le
MTBF est à peine plus élevé que le MUT.
• Le MTTR (Mean Time To Repair ) correspond au temps nécessaire à la réparation
de l’entité et à la reprise du service, temps pendant lequel il est donc inopérant.
• La figure 6 illustre les temps moyens que nous venons de définir et leurs
relations.

1.3 Quelques exemples de domaines d’application

La sûreté de fonctionnement est devenue indispensable dans tous les
secteurs de l’industrie comme la défense, l’aéronautique, l’énergie, mais
aussi les télécommunications ou les transports. Elle est d’ailleurs
omniprésente dans de plus en plus de systèmes informatiques. Par
exemple, des équipements aussi répandus que des PC ou des lecteurs de
CD audio incluent des mécanismes de prise en compte des fautes
permettant de réduire la fréquence de leurs défaillances.
Certains domaines apportent des contextes beaucoup plus exigeants que
la simple utilisation domestique et rendent les aspects de sûreté de
fonctionnement primordiaux au point de devenir une composante
principale de leurs cahiers des charges :
• les applications ou systèmes que l’on peut qualifier de longue-vie : par
exemple les satellites, les sondes spatiales.
• Pour ces systèmes, un objectif premier de sûreté de fonctionnement est
que la probabilité de fonctionner après 5 voire 10 ans d’opération est de
l’ordre de 0,95.
• Ce qui est recherché est formellement une disponibilité élevée mais dans
le but de garantir une durée de vie importante ;
• les applications ou systèmes que l’on peut qualifier de critiques : par
exemple les systèmes de contrôle de vol d’un avion. Pour ces systèmes,
un objectif premier est que la probabilité de fonctionner pendant
quelques dizaines d’heures soit de l’ordre de 0,9999999. Ce qui est
recherché est une fiabilité élevée, une défaillance pouvant mettre en
danger la vie des passagers de l’aéronef. Un autre exemple de système
critique est celui du pilote automatique de métro. Dans ce cas, la sécurité
est souvent privilégiée par rapport à la fiabilité : en cas de défaillance, un
freinage d’urgence peut être déclenché et le système est stoppé ;
• les applications à haute disponibilité : systèmes bancaires, contrôle
aérien, autocommutateurs télécoms. Les objectifs typiques sont par
exemple que le système ne rende pas le service au maximum 3 minutes
par an.
Figure 6 - Quelques temps moyens et leur relation
• 1.4 Entraves à la sûreté de fonctionnement
• Les objectifs (fiabilité, disponibilité, sécurité) à atteindre étant définis, il
convient de formaliser les événements indésirables ou entraves à gérer
afin d’atteindre une sûreté de fonctionnement spécifiée.
• On appelle défaillance d’un système tout comportement du système non
conforme aux spécifications. On appelle erreur un événement interne au
système correspondant à un état révélé d’un composant non conforme
aux spécifications du composant. Le terme révélé signifie que le
composant est dans un état erroné pouvant avoir un impact sur le
comportement du système. On appelle faute le fait qu’un composant d’un
système soit défaillant. Cet état de défaillance peut ne pas être révélé.
L’exemple suivant permet une compréhension plus intuitive de ces
définitions.
• Exemple :
• Un additionneur n’assurant pas la propagation des retenues est fautif.
Ce composant ne respecte, en effet, pas ses spécifications (l’additionneur
se comporte alors comme un Ou Exclusif bit à bit).
• Si on soumet les deux opérandes 0101 et 0011 à cet additionneur, le
résultat r obtenu (0110 au lieu de 1000 ) est une erreur, l’état fautif est
révélé par un résultat incorrect. Si ce résultat est utilisé comme variable
du test suivant, le système présentera une défaillance :

• IF r > 6 THENsignal = rougeELSEsignal = vertFI
• Une défaillance est donc la conséquence d’une ou plusieurs erreurs, elles-
mêmes conséquences de l’utilisation de composants fautifs (composants
affectés de fautes).

• Cela permet de définir la chaîne fondamentale suivante :

• ... Faute ® Erreur ® Défaillance ® Faute ® Erreur ® ...
• Les flèches de cette chaîne expriment la relation de causalité entre faute,
erreur et défaillance. Elles ne doivent pas être interprétées au sens strict.
Une faute ne conduit pas inéluctablement à une erreur et une erreur ne
conduit pas nécessairement à une défaillance.
• Exemple :
• Dans l’exemple précédent, si les opérandes sont 0101 et 0010, le résultat
obtenu (0111 ) est correct. La faute ne conduit pas, dans ce cas, à une
erreur. Si les opérandes sont 1011 et 0011, le résultat erroné obtenu
(1000 ) est strictement supérieur à 6. L’erreur commise ne conduit pas à
une défaillance.

• Ces notions de fautes, erreurs et défaillances sont une voie possible de

« formalisation » des évènements potentiels qu’un concepteur de
système doit étudier et prendre en compte. Cette formalisation est bien
adaptée au travail de conception. Il n’en reste pas moins que d’autres
formalisations peuvent être utilisées, soit pour apporter des compléments
(par exemple, prise en compte de l’environnement avec lequel le système
informatique interagit), soit pour donner un point de vue différent.
• L’utilisation exclusive dans cette section des termes faute, erreur et
défaillance a pour but de montrer que ces trois concepts sont nécessaires
et suffisants pour prendre en compte les entraves à la sûreté de
fonctionnement, cela n’interdisant pas l’utilisation de synonymes dans
des situations particulières. Cependant le terme de panne, bien que d’un
usage courant en français, est d’une utilisation délicate car il peut
désigner tantôt une défaillance (comme dans « tomber en panne »),
tantôt une faute (comme dans « trouver la panne ») ; son utilisation
devient plus que délicate dès que l’on s’écarte des fautes physiques
accidentelles : peut-on raisonnablement parler de « panne de
conception », voire « de panne intentionnelle » ou de « panne
humaine » ? L’utilisation de faute dans ses diverses acceptions permet de
fournir un terme générique qui s’accorde à la généricité de la sûreté de
fonctionnement .
• 1.5 Moyens pour la sûreté de fonctionnement
• Le développement d’un système sûr de fonctionnement passe par l’utilisation
combinée d’un ensemble de techniques qui peuvent être classées en quatre
catégories :
• prévention des fautes : comment éviter l’occurrence ou encore l’introduction
de fautes ;
• élimination des fautes : comment réduire la présence (nombre, sévérité) des
fautes ;
• prévision des fautes : comment estimer la présence, la création et les
conséquences des fautes ;
• tolérance aux fautes : comment fournir un service à même de remplir la
fonction du système en dépit des fautes.
• La prévention des fautes relève de l’ingénierie générale des systèmes et donc
sur la mise en œuvre d’un savoir-faire combinant des méthodologies de
conception et faisant appel à un ensemble de propriétés et de règles de
construction ; cela rejoint d’ailleurs la notion de qualité du logiciel et sort du
seul cadre de la sûreté de fonctionnement. Mais, en dépit de la prévention
des fautes, des erreurs peuvent survenir résultant en des fautes.
• D’où la nécessité de l’élimination des fautes. Celle-ci est constituée de trois
étapes : vérification, diagnostic et correction. La vérification consiste à
déterminer si le système satisfait des propriétés ; si ce n’est pas le cas, les
deux autres étapes sont nécessaires : diagnostiquer la ou les fautes qui ont
empêché les conditions de vérification d’être remplies, puis apporter les
corrections adaptées. Après correction, le processus doit être recommencé
afin de s’assurer que l’élimination de faute n’a pas eu de conséquences
indésirables ; les vérifications ainsi effectuées sont généralement qualifiées de
non-régression. Mais l’élimination des fautes est elle-même imparfaite, de
même que les composants préexistants incorporés dans le système, d’où
l’importance de la prévision des fautes. Cette dernière est conduite en
évaluant le comportement du système par rapport à l’occurrence des fautes
et à leur activation. En adoptant une vue structurelle du système, l’évaluation
consiste à examiner et analyser les défaillances des composants et leurs
conséquences sur la sûreté de fonctionnement du système global. On
distingue l’évaluation ordinale, destinée à identifier, classer et ordonner les
défaillances, ou les méthodes et techniques mises en œuvre pour les éviter,
de l’évaluation probabiliste, destinée à évaluer en termes de probabilités le
degré de satisfaction de certains des attributs de la sûreté de fonctionnement.
• De par la complexité croissante des systèmes informatiques et le
renforcement des contraintes de temps et de budget pour les développer,
des fautes passent inévitablement au travers des méthodes de
prévention, d’élimination voire de prévision. Dans la suite de cet article,
nous nous intéressons essentiellement à la tolérance aux fautes qui reste
indispensable pour que le système continue à fonctionner malgré
l’existence de certaines fautes. Cela est d’autant plus vrai lors de
l’utilisation de logiciels tiers dont on ne maîtrise ni la conception, ni la
réalisation. Par ailleurs, cette technique permet de tirer parti de la
présence des multiples ressources interconnectées entre elles à la
disposition des applications en réseau.
 2. Techniques de la tolérance aux fautes

 2.1 La redondance comme principe de base

2.2 Recouvrement d’erreur
2.2.1 Recouvrement d’erreur par reprise
2.2.2 Recouvrement d’erreur par poursuite
2.2.3 Recouvrement d’erreur par compensation
2.3 Tolérance aux fautes de communications
2.3.1 Communications point-à-point
2.3.2 Communications multipoints
2.4 Techniques pour les systèmes répartis
2.4.1 Consensus
2.4.1.1 Consensus avec perte de messages
2.4.1.2 Consensus avec processus défaillants
2.4.2 Diffusion fiable
2.4.3 Protocole d’élection
2.4.4 Protocole d’appartenance à un groupe
2.4.5 Contrôle de l’accès concurrent aux données
répliquées
2.4.6 Protocole d’engagement atomique
2.4.7 Synchronisation d’horloges physiques et
horloges logiques
2.4.8 Réplication de processus
• Dans cette partie, nous présentons quelques-unes des techniques utilisées
pour obtenir la tolérance aux fautes. Après une introduction des familles de
techniques, nous insistons sur la nécessité d’avoir une certaine redondance
au sein du système à protéger. Nous continuons par une description des
méthodes de recouvrement d’erreur. Nous nous intéressons ensuite aux
fautes de communication puis aux techniques permettant de tolérer les
fautes au niveau des nœuds ou machines formant un système réparti.
• Nous considérons principalement les fautes physiques dues à des
phénomènes physiques adverses par opposition aux fautes dues à l’homme.
La tolérance aux fautes est alors mise en œuvre par deux familles de
techniques complémentaires : le traitement d’erreur et le traitement de
faute. Le traitement d’erreur est destiné à éliminer les erreurs, si possible
avant qu’une défaillance ne survienne. Il fait appel à la détection d’erreur,
qui va permettre le déclenchement de la phase de diagnostic d’erreur pour
estimer les dommages créés par l’erreur et identifier le ou les composants
fautifs du système, information nécessaire au recouvrement d’erreur qui
permet de substituer un état exempt d’erreur à l’état erroné. Le traitement
de faute vise à éviter qu’une ou des fautes ne soient activées à nouveau.
• La première étape est le diagnostic de faute qui consiste à déterminer les
causes des erreurs, en termes de localisation et de nature. Puis vient la
passivation des fautes pour empêcher qu’elles ne se reproduisent à
nouveau. Cela est accompli en retirant les composants considérés comme
fautifs. Si le système ne peut plus délivrer le même service qu’auparavant,
celui-ci peut être dégradé et une reconfiguration peut prendre place en
abandonnant certaines tâches et en réallouant les tâches restantes aux
composants du système.

• 2.1 La redondance comme principe de base

• La conception d’un système tolérant aux fautes fait appel à des

techniques à base de redondance. Il s’agit d’inclure dans le système plus
de ressources que celles strictement nécessaires à la réalisation des
spécifications du système. Les ressources d’un système informatique sont
matérielles, logicielles, informationnelles ou temporelles, donnant lieu à
plusieurs classes de redondance .
Figure 7 - Redondance matérielle par triplication de
processeurs (TMR)
• Redondance matérielle
• La redondance matérielle consiste à utiliser plusieurs dispositifs ou
équipements là où un seul est suffisant en l’absence de fautes. Si l’on
considère comme exemple d’équipement le cas d’un processeur, les
différentes valeurs produites en parallèle par un ensemble de processeurs
sont ensuite comparées entre elles et une décision est prise, le plus
souvent par un vote majoritaire. La figure 7 donne l’exemple d’un système
conçu avec une triplication (ou TMR Triple Modular Redundancy ) des
processeurs et l’ajout d’un voteur réalisant un vote majoritaire.
• Redondance logicielle
• La redondance logicielle (encore appelée redondance spatiale) peut
prendre des formes similaires à celle de la redondance matérielle.
• On peut, par exemple, réaliser en logiciel une structure NMR (N Modular
Redundancy ) où N copies d’un logiciel sont exécutées afin de produire N
résultats qui seront soumis à un logiciel de vote majoritaire . Cette
technique permet de masquer t erreurs simultanées avec N = 2 t + 1.
• Une autre solution consiste à réaliser des programmes produisant des
résultats sur lesquels un test de correction peut être effectué.
• Exemple :
• la figure 8 donne l’exemple de l’utilisation de « checksums » sur les lignes
et colonnes de matrices pour protéger le calcul de l’addition matricielle.
• Des algorithmes spécifiques ont été conçus, par exemple pour le produit
de matrices ou la transformée de Fourier.

Figure 8 - Addition de matrices avec

contrôle par des checksums
• Redondance temporelle
• Si les fautes sont identifiées comme transitoires, et si les contraintes de
l’application sont compatibles avec les techniques de recouvrement
d’erreur, il est possible d’appliquer une technique d’exécutions
successives multiples ou de redondance temporelle. Ce type de
redondance implique un surcoût important lié à la détection d’une erreur
et à la séquentialité des exécutions multiples.
• L’approche transactionnelle  utilisée dans les systèmes de gestion de
bases de données repose sur la redondance temporelle. Une transaction
correspond à l’exécution d’un programme ou ensemble de traitements
accédant à des données partagées. Le programme transforme les données
d’un état initial où les données sont mutuellement cohérentes en un
autre état similairement cohérent. Pour garantir la cohérence, le
programme doit pouvoir se terminer prématurément, en provoquant la
restauration de l’état initial. Une nouvelle exécution du programme est
alors lancée et plusieurs exécutions successives peuvent se produire.
• Les retransmissions des protocoles de transmission de données sont un
autre exemple de redondance temporelle.
• Redondance informationnelle
• Des informations supplémentaires sont ajoutées afin de faciliter la
détection d’erreurs et éventuellement le recouvrement de ces erreurs.
Cela est utilisé dans les codes détecteurs d’erreur, les codes correcteurs
d’erreur, comme le code de Hamming, ainsi que dans le mécanisme des
disques RAID5 (Redundant Array of Inexpensive Disks ).
• Toutes les techniques utilisées dans la conception de systèmes tolérants
aux fautes physiques reposent sur des mécanismes utilisant ces divers
types de redondance. La typologie des redondances donnée ici n’est pas
un classement au sens strict. En effet, une technique donnée peut relever
de plusieurs types de redondance.
• Exemple :
• Par exemple, les circuits auto-testables  utilisent du matériel
supplémentaire (redondance matérielle) pour traiter et produire des
informations codées (redondance informationnelle).
• 2.2 Recouvrement d’erreur
• Cette technique permet de substituer un état exempt d’erreur à l’état
erroné. Cette substitution peut elle-même prendre trois formes :
• reprise : le système est ramené dans un état correct survenu avant
l’occurrence de l’erreur ;
• poursuite : un nouvel état est trouvé à partir duquel le système peut
fonctionner (éventuellement en mode dégradé) ;
• compensation d’erreur : l’état erroné comporte suffisamment de
redondance pour permettre sa transformation en un état correct.

• 2.2.1 Recouvrement d’erreur par reprise

• La reprise consiste à revenir en arrière vers un état antérieur correct. Cela
nécessite d’enregistrer des points de reprise en mémoire stable, à partir
desquels un état cohérent peut être restauré. L’avantage de cette
technique est d’être générale et indépendante de l’application.
• Cependant, plusieurs difficultés lui sont liées : la sauvegarde et la
restauration d’un point de reprise doivent être atomiques (opérations
exécutées intégralement ou pas du tout) ; les points de reprise doivent eux-
mêmes être exempts de fautes ; dans le cas d’un système réparti, l’ensemble
des points de reprise de chaque processus impliqué dans l’application doit
constituer un état global cohérent du système, ce qui est un problème réputé
difficile.
• Nous présentons maintenant trois catégories d’approches pouvant être
utilisées pour la création des points de reprise : pessimiste, optimiste et
préprogrammée. Une autre approche basée sur des points de reprise
logiques et non physiques a été proposée par .
• Pessimiste - Les processus créent des points de reprise de manière
synchrone représentant un état global cohérent.
• Cela est destiné principalement à éviter l’effet de domino  (les processus
doivent être restaurés à leur point de départ du fait de l’absence d’un état
global cohérent autre que l’état initial) et convient même si les processus ne
sont pas déterministes. Certaines méthodes synchrones nécessitent de
suspendre les processus en cours lors de la création des points de reprise.
Cela n’est pas possible dans toutes les applications.
• Dans cette approche, la valeur de la période d’établissement des points de
reprise est un problème crucial. Avec une période faible, la fréquente
création des points de reprise engendre un coût important tandis que plus
la valeur est élevée et plus le nombre de transactions devant être
réexécutées sera grand.
• Dans les méthodes dites pessimistes (ou synchronisées), chaque message
reçu est enregistré sur mémoire stable avant d’être traité. Cela garantit
que les informations en mémoire stable à travers le système sont toujours
cohérentes. Cependant, cette méthode ralentit le traitement de
l’application. Pour diminuer ce coût, des mécanismes matériels peuvent
être utilisés pour la synchronisation des horloges de tous les processeurs.
• Optimiste - Les processus créent des points de reprise de manière
asynchrone et indépendante.
• Lors de la défaillance d’un processeur, il est nécessaire de déterminer un
ensemble de points de reprise représentant un état global cohérent. Cette
technique minimise le surcoût en fonctionnement normal en l’absence
d’erreurs, au prix d’un coût élevé pour la recherche d’un état global
cohérent.
• Puisqu’il n’y a pas de synchronisation entre les calculs, les
communications et la création des points de reprise, cette approche
permet de tolérer un nombre arbitraire de défaillances. De plus, quand les
défaillances sont très rares, elle donne un meilleur débit et un meilleur
temps de réponse que les méthodes générales.

• La création des points de reprise est préprogrammée afin de générer un

état global cohérent.

• Cela peut se faire en enregistrant à chaque envoi de message un point de

reprise local. Le recouvrement d’un processus est ensuite possible de
façon indépendante des autres processus. Mais cette méthode est très
coûteuse en temps et risque de détériorer les performances. Une autre
solution consiste à utiliser des conversations.
• Une conversation permet la structuration des interactions entre des
processus. Elle contient un bloc de recouvrement d’erreur qui englobe un
ensemble d’opérations, un test d’acceptation permettant de valider les
traitements et un ensemble d’alternatives exécutées si une erreur est
détectée. La figure 9 donne des exemples de conversations entre trois
processus X, Y et Z. Des points de reprise, de A à H, sont positionnés dans
chaque conversation. Une conversation peut être vue comme une zone
de confinement empêchant une erreur de se propager. À l’intérieur d’une
conversation, plusieurs processus peuvent communiquer librement entre
eux mais pas avec des processus ne faisant pas partie de la conversation.
Les processus peuvent entrer dans une conversation à des instants
différents ; cependant, ils doivent tous quitter la conversation ensemble
après satisfaction de leurs tests d’acceptation respectifs. En cas de
défaillance de l’un des processus, il est procédé à la reprise automatique
de tous les processus de la conversation afin d’exécuter l’une des
alternatives prévues, sans perturbation sur les processus en dehors de la
conversation défaillante.
Figure 9 - Exemples de conversations entre trois processus
• On peut également classer dans cette catégorie l’approche transactionnelle.
Les différents états cohérents d’une transaction doivent être sauvegardés en
mémoire stable afin de constituer de potentiels points de reprise.

• 2.2.2 Recouvrement d’erreur par poursuite

• La poursuite nécessite de trouver un nouvel état correct à partir duquel le
système peut fonctionner (généralement en mode dégradé). Cette technique
reste spécifique et dépendante de l’application. La recherche d’un nouvel état
acceptable consiste souvent en une réinitialisation du système et en
l’acquisition d’un nouveau contexte d’exécution auprès de l’environnement.

• 2.2.3 Recouvrement d’erreur par compensation

• La compensation (ou masquage d’erreur) est possible lorsque l’état erroné
comporte suffisamment de redondance interne pour détecter et corriger
l’erreur. Le traitement d’erreur a alors l’avantage d’être rapide, mais nécessite
une redondance structurelle d’un coût élevé.
• Exemple :
• Un exemple de mécanisme de compensation est donné par les codes
correcteurs d’erreur : la validité de la valeur codée est vérifiée en
permanence et tout mot hors code est systématiquement remplacé par le
mot du code le plus proche.

• 2.3 Tolérance aux fautes de communications

• Nous donnons dans ce paragraphe un aperçu des problèmes pouvant
survenir au niveau des communications point-à-point et multipoints. Pour
plus d’informations sur ce sujet, le lecteur pourra se référer à et.

• 2.3.1 Communications point-à-point
• Une communication point-à-point fiable est en général obtenue en utilisant
un protocole de transport fiable tel que TCP (Transmission Control
Protocol ). TCP masque les pertes de messages en utilisant des accusés de
réception et des retransmissions. Ces fautes par omission sont alors
complètement cachées aux applications TCP.
• Cependant, une perte de connexion ne peut être facilement masquée. Cela
peut se produire lorsqu’une connexion TCP est interrompue brutalement
et qu’aucun message ne peut plus être transmis. En général, il en résulte
une exception qui est transmise à l’application. L’un des moyens pour
masquer ce genre de fautes est d’avoir une couche intermédiaire, telle que
l’on trouve dans les systèmes répartis dans ce que l’on appelle le
middleware, chargée de construire une nouvelle connexion
automatiquement. Dans ce cadre, il est important de comprendre la
sémantique des couches de communication sous-jacentes telles que les
RPC (Remote Procedure Call - Appels de Procédure à distance) sur
lesquelles reposent de très nombreux middleware.
• Le but des RPC est de masquer les communications à distance en rendant
un RPC similaire à un appel local. Cela est réalisé en générant une
procédure locale ou souche cliente qui se charge d’emballer les arguments
dans une requête et d’attendre une réponse. Cette requête est alors
transmise par le réseau à une souche serveur capable de déballer les
arguments, d’appeler la procédure demandée et de renvoyer le résultat.
Cependant, en cas d’erreurs, les différences entre appel local et appel
distant ne sont pas toujours faciles à masquer.
• On peut distinguer cinq classes différentes de défaillances pouvant se produire
avec les RPC.

•  1.Le client n’arrive pas à localiser le serveur. Celui-ci peut être arrêté pour une
raison quelconque, ou encore il peut y avoir une incompatibilité entre le client
et le serveur due par exemple à une mise à jour du serveur entre le moment où
le client a été installé et celui où il invoque effectivement le service prévu. Une
solution possible revient à prévoir un traitement d’exception approprié, en
réduisant malheureusement le niveau de transparence fourni par les RPC, un
appel local et un appel distant n’étant plus complètement équivalents.
•  2.La requête du client vers le serveur est perdue. Ce cas peut être géré au
niveau du système d’exploitation ou de la souche cliente en armant un
temporisateur lors de l’émission de la requête. Si ce temporisateur expire avant
la réception d’une réponse, la requête est simplement réémise. Si la requête
n’était finalement pas perdue, le serveur doit pouvoir détecter qu’il y a eu
réémission d’une même requête.
•  3.Le serveur tombe en panne après la réception d’une requête. Le problème
est différent selon que le serveur tombe en panne avant ou après avoir traité la
requête et préparé une réponse.
• On distingue alors plusieurs solutions. Avec la technique garantissant la
sémantique d’invocation « au moins une fois », la souche cliente continue
à réémettre la requête tant qu’elle ne reçoit pas de réponse. Avec la
technique « au plus une fois », la requête est abandonnée et un rapport
d’erreur est transmis à l’application cliente. Cela implique que la requête
peut ne pas être exécutée. La sémantique idéale « exactement une fois »
est en général très difficile à garantir.

•  4.La réponse du serveur vers le client est perdue. Comme dans le cas de
la perte d’une requête, la solution se base le plus souvent sur un
temporisateur avec réémission de la requête. Cependant, le client ne peut
pas savoir facilement pourquoi il ne reçoit pas de réponse : le message de
requête ou de réponse peut être perdu, ou simplement le serveur peut
être lent. Un moyen de se prémunir contre d’éventuelles incohérences, en
cas d’exécutions multiples d’une même requête, est de ne manipuler que
des opérations idempotentes. Une autre solution consiste à marquer
chaque requête d’un numéro de séquence afin de différencier une
nouvelle requête et une réémission.
Nota :
• une opération est idempotente lorsque l’exécution répétée de cette
opération produit toujours le même résultat.
•  5.Le client tombe en panne après l’envoi d’une requête. La requête devient
alors orpheline et peut causer de nombreux problèmes comme la
consommation inutile de temps machine ou le verrouillage de ressources.
Plusieurs solutions sont envisageables :
• l’extermination : cela nécessite la journalisation préalable des requêtes
clientes avant leur envoi pour pouvoir identifier les requêtes orphelines ;
• la réincarnation : le temps est découpé en époques. Lorsqu’un client
redémarre, il initialise une nouvelle époque et diffuse un message à toutes
les machines. Tous les traitements en cours pour ce client sont alors avortés ;
• la réincarnation douce : seules les requêtes dont le demandeur ne peut être
retrouvé sont annulées ;
• l’expiration : une requête doit être traitée en un temps T, sinon un nouveau
délai doit être demandé. La difficulté est ici dans le choix d’une valeur
raisonnable du délai T.
• 2.3.2 Communications multipoints
• Pour des communications multipoints, des mécanismes de plus haut niveau
que le niveau transport doivent être fournis, en tirant partie des propriétés
de fiabilité du protocole TCP. Lorsque le nombre n de participants est faible,
la solution la plus simple est de mettre en place n canaux de communication
point-à-point. Mais lorsque n devient grand, cela n’est plus viable en terme
de bande passante du réseau. De nombreuses propositions ont été faites
dans la littérature, dont les plus représentatives utilisent des messages de
retour (feedback ) avec contrôle, hiérarchique ou non. Pour une
comparaison des différentes solutions, le lecteur pourra se référer à .
• Le protocole SRM (Scalable Reliable Multicasting )  permet la diffusion de
messages au sein d’un groupe avec un contrôle non hiérarchique. Lorsqu’un
message a été perdu (la détection d’une perte du message étant laissée à
l’application), le récepteur R envoie un déni de réception à l’ensemble du
groupe, après avoir attendu un temps aléatoire (temps devant être différent
sur les différents membres du groupe). Si, pendant ce délai, R reçoit un déni
d’un autre membre du groupe sur le même message, il supprime en fait son
message de retour et ne l’envoie pas.
• En effet, l’émetteur ayant déjà reçu un déni retransmettra le message
perdu prochainement. Le passage à l’échelle peut être amélioré en
autorisant un membre du groupe ayant reçu correctement le message m
de le rediffuser avant que l’émetteur original ne le fasse.
• Cependant, pour un passage à très grande échelle, un contrôle
hiérarchique est indispensable. Il s’agit de décomposer l’ensemble des
sites communicants en sous-groupes et d’organiser ces sous- groupes en
une structure d’arbre. Un protocole de diffusion suffisant pour un petit
nombre de destinataires peut alors être utilisé au sein de chaque sous-
groupe. Un coordinateur doit être désigné dans chaque sous-groupe pour
centraliser les demandes de retransmission de ses membres.

• 2.4 Techniques pour les systèmes répartis

• Un système réparti est défini comme un ensemble de nœuds ou
processeurs (avec éventuellement une mémoire locale), possédant
chacun sa propre horloge et reliés uniquement par un réseau de
communication par messages.
• La tolérance aux fautes dans de tels systèmes doit prendre en compte des
contraintes supplémentaires  :
• le traitement des erreurs et des fautes ne peut se faire que par échange de
messages ;
• la granularité des techniques de recouvrement, de masquage d’erreur et de
reconfiguration est celle des processus communicants ou des données
réparties ;
• l’état global du système doit être maintenu cohérent, bien que non
directement observable, ni a fortiori manipulable.
• On identifie plusieurs types de systèmes répartis suivant les hypothèses faites
sur les délais de communications et sur les types de fautes des processeurs et
des moyens de communication. S’il existe des bornes minimales et maximales
sur les délais de communication et de traitements, on se place dans le cadre
d’un système synchrone ; on suppose alors également que le réseau de
communication est parfait dans le sens où le système ne peut pas être
partitionné. En l’absence de bornes connues, le système est asynchrone. Il a
été prouvé que des algorithmes déterministes n’existent pas pour de tels
systèmes ; le résultat le plus connu concerne l’impossibilité d’obtenir un
consensus dès lors qu’un processus au moins est susceptible d’être défaillant .
• Concernant les modes de fautes, on distingue les fautes par arrêt, les fautes
par omission, les fautes temporelles et les fautes arbitraires ou byzantines.
• Il est à noter que toute architecture possédant une redondance structurelle
peut être vue comme un système réparti et pourra tirer profit des
algorithmes répartis fondamentaux nécessaires à la tolérance aux fautes que
nous présentons ci-après. Le lecteur intéressé par les résultats théoriques liés
à la plupart de ces algorithmes pourra se référer à.

• 2.4.1 Consensus
• Dans le cas d’une redondance massive (n > 2), il est souvent nécessaire
d’effectuer un vote réparti sur une valeur calculée n fois afin de rechercher
un consensus. La valeur peut ensuite être utilisée comme un signal pour
déclencher un traitement (cas d’une valeur binaire), ou bien elle peut
correspondre à une donnée quelconque. Dans le cas d’un système idéal,
stable et sans erreur, un consensus est en général facilement obtenu par un
simple échange de messages. Le fait que les processus participant au vote
puissent subir des défaillances, aussi bien au niveau des canaux de
communication que des processeurs, rend le problème beaucoup plus
difficile.
• Cependant, le paradigme du consensus revêt une importance particulière
car il peut être utilisé comme brique de base pour résoudre de nombreux
problèmes d’accord tels que l’ordre total (nécessaire pour la diffusion
atomique notamment), l’engagement atomique, l’appartenance à un
groupe et l’élection . Cela explique que ce problème fondamental des
systèmes répartis a suscité et suscite encore de très nombreux travaux de
recherche.

• 2.4.1.1 Consensus avec perte de messages

• Dans le cas de canaux de communication non fiables, seules des solutions
non-déterministes impliquant certains compromis et une marge d’erreur
inévitable peuvent être mises en place. Une solution basée sur des
processus au comportement aléatoire a été proposée par , mais ses
performances moyennes ne la rendent pas toujours applicable. Dans la
pratique, une solution consiste à multiplier les canaux de communication
mais elle entraîne un coût de réalisation non négligeable.
• 2.4.1.2 Consensus avec processus défaillants
• Deux cas de défaillances sont considérés : les défaillances franches par
arrêt d’une machine suite à un crash par exemple, et les défaillances
arbitraires ou byzantines correspondant à tout type de
dysfonctionnement des processeurs. Dans les deux cas, f étant le nombre
maximal de processus défaillants, une solution ne peut pas être obtenue
en moins de f + 1 itérations. Dans le deuxième cas, il a de plus été prouvé
qu’il faut 3 f + 1 processus au total.
• Un protocole de consensus doit satisfaire les quatre propriétés suivantes :
• terminaison : chaque processus correct décide finalement d’une valeur ;
• validité : si un processus décide d’une valeur v, alors cette valeur a été
préalablement proposée par un processus participant ;
• entente : deux processus corrects ne décident pas d’une valeur différente ;
• intégrité : un processus ne décide qu’une seule fois d’une valeur.
• De nombreux algorithmes de consensus existent avec des hypothèses de
défaillance différentes et des types de détecteurs de défaillance parfaits ou
moins exigeants.
• Nous présentons ci-après l’un des premiers algorithmes proposés avec un
certain degré d’indulgence, tolérant le fait qu’un processus correct peut être
suspecté d’être défaillant et reposant sur une majorité de processus corrects.
Les détails de cet algorithme sont décrits dans. Cet article introduit
également la notion de détecteur de défaillance, externe à l’algorithme de
consensus ; ce mécanisme maintient une liste de processus suspectés de
défaillance dont il peut fournir l’état à un instant donné à tout processus
demandeur ; la liste peut être plus ou moins correcte et les informations
peuvent varier au cours du temps.
• L’algorithme procède par itérations successives ; le leader de l’itération i est
le processus de numéro (i mod N ) + 1 où N est le nombre total de processus.
Une itération est constituée des cinq phases suivantes :
•  1.Calcul. Le processus leader commence par calculer la valeur qu’il va
proposer. Tous les participants doivent envoyer leur valeur courante au
leader qui sélectionne la valeur ayant l’estampille la plus élevée. La sélection
commence dès que le leader a reçu une réponse d’une majorité de
processus. Le leader envoie ensuite aux autres processus par une diffusion
simple la valeur qu’il vient de décider.
•  
• 2.Adoption. Après la réception d’une nouvelle proposition, chaque
processus participant l’adopte en lui attribuant une estampille
correspondant au numéro de l’itération courante.
•  3.Envoi d’accusés de réception. Chaque processus ayant adopté la
valeur proposée par le leader envoie un accusé de réception au leader. Le
processus peut alors directement passer à l’itération suivante.
•  4.Décision. Si le leader reçoit une majorité d’accusés de réception et
aucun déni de réception, il décide que la proposition est adoptée et
informe l’ensemble des participants par une diffusion fiable. Dans le cas
de la réception d’au moins un déni de réception, l’itération en cours est
interrompue et l’itération suivante est lancée.
•  5.Décision globale. Tout processus recevant un message de décision
décide effectivement la valeur indiquée.
• Le point critique de chaque itération est de savoir combien de temps un
participant doit attendre une proposition du leader. Après un délai limite
fixé au départ, un processus consulte le détecteur de défaillance pour avoir
une idée de l’état courant du leader. Le détecteur de défaillance utilisé est
du type « finalement parfait » garantissant qu’il existe un temps t au bout
duquel un processus correct n’est plus suspecté et qu’un processus
défaillant sera finalement suspecté par tout processus correct. En cas de
suspicion, le processus en attente du leader lui envoie un déni de réception
et passe à l’itération suivante.

• 2.4.2 Diffusion fiable
• La diffusion est largement utilisée dans la réplication de processus. Elle doit
donc être fiable même en présence de fautes au niveau des processeurs ou
des liens de communication. Un protocole de diffusion est fiable s’il a les
trois propriétés suivantes :
• validité : si un processus correct diffuse un message m alors tous les
processus corrects reçoivent ce message ;
• entente : tous les processus sont d’accord sur ce qui est reçu ;
• intégrité : pour tout message m, chaque processus correct ne reçoit m
qu’une seule et unique fois (sachant que m a été préalablement émis par
un processus donné).
• La notion d’ordre est également très importante dans la gestion de
groupes de processus. On peut distinguer quatre niveaux concernant
l’ordre de délivrance des messages à l’intérieur d’un groupe.
• aucune garantie : les processus corrects reçoivent les messages mais dans
n’importe quel ordre ;
• ordre FIFO (First In, First Out ) : tous les messages diffusés par un
processus donné sont délivrés dans l’ordre où ils sont émis ;
• ordre causal : si la diffusion d’un message m précède causalement  la
diffusion de m ′, alors aucun processus correct ne remet m ′ avant d’avoir
remis m ;
• ordre total : toutes les destinations reçoivent les messages dans le même
ordre.
• Une diffusion fiable avec ordre total est dite atomique.
• Pour un type de diffusion donné, les différents protocoles se distinguent
selon les hypothèses faites relativement  :
• aux membres du groupe : mode de défaillance supposé, nombre maximal
de défaillances tolérées... ;
• au système de communication sous-jacent : mode de défaillance supposé,
qualité de service (délais maximaux garantis par exemple)... ;
• aux horloges utilisées : une horloge globale, ou des horloges locales.

• 2.4.3 Protocole d’élection
• Lorsqu’une solution à un problème est basée sur l’existence d’un site
coordinateur unique, la défaillance de ce coordinateur doit être tolérée.
Un protocole d’élection permet de désigner un et un seul coordinateur
remplaçant. Il existe de nombreux algorithmes d’élection. Ils font tous
l’hypothèse que les processus participants sont numérotés de manière
unique et que chaque processus connaît le numéro des autres processus.
Le processus de numéro maximal est ensuite élu.
• Les différents algorithmes varient en termes de complexité, d’hypothèses sur le
réseau (topologie, synchrones ou asynchrones...), de mécanismes de choix d’un
processus (par comparaison des numéros ou par manipulation de ceux-ci au
travers d’opérations arithmétiques) et de nécessité de connaître le nombre total
n de processus participants.
• Dans le cas d’un réseau synchrone bidirectionnel en anneau, le premier
algorithme nécessitant dans le cas le pire O(n log n ) messages a été proposé par
Hirschberg et Sinclair . Cet algorithme peut facilement être adapté pour un réseau
asynchrone. Des solutions pour des réseaux asynchrones unidirectionnels ont par
ailleurs été proposées par  et.

• 2.4.4 Protocole d’appartenance à un groupe

• Il s’agit d’assurer que tous les usagers ayant à connaître la situation d’un groupe
de serveurs atteignent un consensus sur la composition de ce groupe. La
perception de cette composition est relative aux informations échangées entre les
processeurs et nécessite donc un protocole de diffusion fiable. Un service de
groupe peut être défini avec seulement trois opérations de base : join() pour
demander à faire partie d’un groupe, leave() pour quitter à tout instant un groupe
et monitor() pour suivre l’état d’un autre processus du groupe .
• Plusieurs protocoles ont été proposés. Par exemple, peut être utilisé dans des
réseaux asynchrones où les processus peuvent être corrompus (cas des
fautes byzantines). Le problème des fautes arbitraires ou malicieuses a été
soulevé pour la première fois par  dans leur article sur les généraux byzantins.
Avec des messages oraux simples, il est prouvé qu’une solution existe à
condition que plus des deux tiers des membres du groupe soient
opérationnels à tout instant, chaque participant étant capable de confondre
deux traîtres. Cela est le cas du protocole défini dans. Avec des messages
signés et sécurisés, une solution existe pour n’importe quel nombre de
participants et de traîtres.

• 2.4.5 Contrôle de l’accès concurrent aux données

répliquées
• Si l’application met en œuvre des données réparties partagées sur différents
sites, il faut assurer le contrôle de l’accès concurrent aux données répliquées
pour maintenir leur cohérence. On distingue les protocoles pessimistes et
optimistes suivant qu’ils garantissent ou non la cohérence des copies lors
d’un partitionnement du réseau .
• Les protocoles pessimistes n’autorisent l’accès qu’à un seul sous-ensemble
de copies à la fois afin d’en assurer la cohérence. Le mécanisme utilisé est le
plus souvent un verrou pour exclure les accès concurrents lorsqu’une lecture
ou une écriture est en cours. Les protocoles optimistes font l’hypothèse que
les accès conflictuels sont très rares et favorisent la disponibilité des
données au risque d’une perte éventuelle de leur cohérence. Les
incohérences doivent ensuite être détectées et corrigées, automatiquement
ou le plus souvent manuellement.

• 2.4.6 Protocole d’engagement atomique

• Un tel protocole, encore appelé protocole de validation atomique, doit être
mis en œuvre lors de la réalisation de points de reprise sur support stable
local afin de synchroniser l’écriture des différentes données modifiées par
une transaction répartie. Le protocole le plus utilisé est le protocole à deux
phases (2 Phase Commit ). Dans la plupart des implémentations de ce
protocole, la diffusion est réalisée par simple envoi de messages à tous les
participants ; des cas de blocage peuvent survenir par exemple lorsque le
coordinateur défaille lors de la diffusion de la décision.
• La diffusion doit être fiable pour que le protocole soit non-bloquant.

• 2.4.7 Synchronisation d’horloges physiques et

horloges logiques
• L’absence d’une horloge physique globale dans un système réparti est un
problème crucial. La synchronisation d’horloges physiques permet
d’assurer que des horloges situées sur des sites distincts fournissent une
datation absolue des événements avec une incertitude définie. Pour ce
faire, deux sous-problèmes doivent être résolus :
• assurer que différents sites arrivent à démarrer avec la même heure
absolue (au même moment, à une incertitude connue près) ;
• maintenir aussi longtemps que nécessaire les différentes horloges dans
une variation relative connue.
• Les principales solutions existantes procèdent soit par échange de
messages, soit par asservissement sur une horloge hertzienne ou en
provenance d’un satellite.
• Dans cette deuxième catégorie, le protocole NTP (Network Time Protocol )
offre une précision de l’ordre de la dizaine de millisecondes en réseau
étendu et inférieure à la milliseconde en réseau local .
• Afin de dater les évènements, des horloges logiques vectorielles peuvent
être définies afin de rendre compte de la relation de causalité entre les
évènements . Chaque site gère une horloge vectorielle constituée de n
entiers (n étant le nombre de sites composant le système). Une telle
horloge permet de dater les évènements d’un site et est mise à jour lors
de l’occurrence des évènements. Les messages envoyés par un site sont
estampillés en utilisant la valeur courante de l’horloge vectorielle du site
émetteur et la réception d’un message permet au site récepteur de
synchroniser son horloge vectorielle avec celle du site émetteur du
message.
• 2.4.8 Réplication de processus
• Comme nous l’avons déjà vu, la tolérance aux fautes est principalement
obtenue par redondance. Nous traitons dans cette partie de la redondance
spatiale mise en œuvre de manière naturelle dans les systèmes répartis en
répliquant les processus sur des processeurs différents. Les hypothèses de
base considèrent que le réseau est fiable et que les serveurs et les
messages sont clairement identifiés. Dans le projet Delta-4 , trois
approches pour la réplication ont été proposées et mises en œuvre.
• Réplication active (ou approche par machine à états ). Chaque processus
d’une application est en fait exécuté par n processus d’une manière
concurrente. Tous les processus répliqués reçoivent l’ensemble des
messages d’entrée qui sont diffusés à tout le groupe d’une manière
concurrente afin de garder les états internes des processus parfaitement
synchronisés ; cela nécessite une diffusion atomique (fiable avec ordre
total). Cette technique permet de réaliser facilement un vote sur les
valeurs de sortie afin de tolérer des fautes arbitraires . L’exécution doit
être parfaitement déterministe. Le coût est élevé en l’absence de faute,
mais le recouvrement d’erreur est immédiat.
• Dans le cadre du projet Delta-4, le protocole IRp (Inter-Replica protocol ) est
utilisé pour assurer la délivrance d’un message à toutes les répliques d’une
manière transparente et pour effectuer un arbitrage entre les ordres d’envoi
des messages afin que les destinations ne reçoivent chaque message qu’en
un seul exemplaire.
• Réplication passive. C’est une technique de recouvrement par reprise dans
laquelle un seul des processus répliqués, appelé le processus primaire, traite
les messages d’entrée et fournit les messages de sortie. Ces messages de
sortie ne sont utilisés par les autres processus (processus secondaires) qu’en
cas de défaillance du processus primaire. En fonctionnement normal, leur
état interne est mis à jour régulièrement par des points de contrôle que leur
envoie le processus primaire. Seule une diffusion fiable est nécessaire,
associée à un mécanisme de gestion de groupe (sauf s’il y a un seul serveur
de secours, ce qui reste très fréquent). Il n’est pas nécessaire que l’exécution
soit déterministe mais les processeurs doivent être à silence sur défaillance.
L’envoi fréquent de points de contrôle entraîne un coût important ; cette
technique peut donc ne pas convenir dans le cas d’un système temps réel,
ou bien lorsque les fautes sont fréquentes. De plus, la reprise n’est pas
immédiate pour permettre la restauration d’un point de contrôle.
• Réplication semi-active. Il s’agit d’une technique hybride combinant les
réplications active et passive. Comme dans la réplication passive, les
messages d’entrée sont diffusés à toutes les répliques, mais seul le
processus primaire fournit les messages de sortie. L’état interne des autres
processus est mis à jour soit par le traitement direct des messages d’entrée,
soit par des notifications (ou mini-points de contrôle) envoyées par le
leader. Cela limite donc les inconvénients de la réplication passive où les
mises à jour se font par l’envoi de points de contrôle de grande taille et
permet d’utiliser cette technique dans les systèmes temps réel. En général,
pour la réplication semi-active, les processeurs doivent être à silence sur
défaillance afin d’éviter la propagation d’une notification issue d’un leader
défaillant. Cependant, cette contrainte peut être ignorée de la façon
suivante : chaque notification indique le choix du leader parmi un ensemble
fini et prédéterminé de décisions. Lorsqu’un processus secondaire reçoit
une notification n’appartenant pas à cet ensemble, une erreur est détectée
et une décision par défaut est appliquée.
• La réplication passive reste la plus utilisée dans les applications courantes,
comme par exemple les systèmes d’informations. La réplication active est
par contre mieux adaptée à des applications critiques ou temps réel.
• Toutes ces techniques de réplication nécessitent de conserver le degré de
réplication presque constant afin de tolérer des défaillances successives.
Elles doivent donc être associées à un traitement de fautes prévoyant des
procédures de reconfiguration permettant de lancer et d’initialiser de
nouvelles répliques.
 3. Approches pratiques

• 3.1 Architectures en grappe
3.1.1 Principales caractéristiques
3.1.2 Architecture Sun Cluster
3.2 Tolérance aux fautes dans CORBA
3.3 RSERPOOL
3.3.1 Profil minimal
3.3.2 Profil complet
• La tolérance aux fautes étant souvent conçue de manière ad hoc, l’émergence
de solutions commerciales de bonne qualité est un fait récent mais marquant
qui contribuera à l’amélioration de la fiabilité des applications. Nous
mentionnons tout d’abord les architectures en grappe pour lesquelles les
constructeurs informatiques fournissent aujourd’hui des solutions clés en
main pour la haute-disponibilité des applications et donnons comme exemple
le produit Sun Cluster. Puis nous présentons les travaux de deux consortiums
de normalisation, l’OMG (Object Management Group ) pour les applications à
base d’objets distribués et l’IETF (Internet Engineering Task Force ) pour les
applications Internet.

• 3.1 Architectures en grappe
• 3.1.1 Principales caractéristiques
• Les architectures basées sur une grappe (ou « cluster ») de machines
standards interconnectées entre elles sont de plus en plus répandues. Une
architecture en grappe est généralement vue comme ayant les
caractéristiques suivantes .
 
• •Composants standards : le moteur principal de la réalisation
d’architectures en cluster est de bénéficier de matériel standard et peu
coûteux produit à grande échelle ; ainsi une grappe est le plus souvent
construite à partir de composants standards, sans nécessairement utiliser
d’écran. Une grappe contient en général deux types de composants, les
nœuds de calcul et les disques de stockage.
•  •Système d’exploitation en local : chaque nœud de la grappe utilise son
propre système d’exploitation, qui peut être vu comme un composant
logiciel standard. Cela différencie de telles architectures à la fois des
machines multiprocesseurs, où un système d’exploitation unique est
capable de gérer plusieurs nœuds à la fois et du matériel dédié offrant
une mémoire partagée, et également des architectures parallèles dans
lesquelles une version allégée du système d’exploitation est utilisée sur
chaque nœud.
• •Réseau d’interconnexion rapide : le bus interne reliant les composants
est le plus souvent orienté message et basé sur une technologie haute
vitesse telle que ATM (Asynchronous Transfer Mode) ou CSMA (Carrier
Sense Multiple Access).
•  •Système de gestion : celui-ci joue un rôle majeur pour offrir
l’abstraction d’une entité parfaitement intégrée et pouvant être vue
comme une cible de déploiement unique.
•  •Interface de programmation : un ensemble d’opérations est défini afin
que les programmeurs et les administrateurs puissent exploiter toute la
puissance de la grappe de machines. Cela inclut des opérations pour
connaître le nombre de machines de la grappe, surveiller leur état, lancer
et surveiller l’exécution des applications, etc.
• Certaines architectures en grappe offrent des propriétés spécifiques qui
les rendent particulièrement bien adaptées aux applications critiques
ayant des besoins importants de sûreté de fonctionnement, mais les
objectifs de construction de ces architectures sont très variés.
•  •Haute-disponibilité : certaines architectures offrent des garanties de
disponibilité de 99,999 % du temps telles que ce qui est exigé par les
applications critiques.
• Cela implique l’utilisation de matériel, infrastructure de communication,
système d’exploitation appropriés.
•  •Mécanisme de basculement (failover ) : lorsqu’un nœud de la grappe
subit une défaillance ou est indisponible, ce mécanisme permet de
basculer les traitements en cours sur ce nœud vers un autre nœud
disponible.
•  •Pas de point de défaillance unique : pour une application fiable, cela
est la condition minimale que doit remplir le système ; la défaillance d’un
composant ne doit pas paralyser l’ensemble du système. Cette propriété
doit prendre en compte aussi bien les composants matériels que logiciels.
•  •Synchronisation d’horloges : certaines architectures sont capables de
synchroniser les horloges de manière très précise.
•  •Communications fiables : grâce à du matériel de communication
spécifique, de nombreuses architectures garantissent la fiabilité des
communications.

• 3.1.2 Architecture Sun Cluster

• Depuis 1997, Sun Microsystems commercialise une solution de haute-
disponibilité dont la dernière version Sun Cluster 3.1. 10/03 compatible
avec Solaris 8 et Solaris 9 est sortie en 2003.
Figure 10 - Architecture simplifiée de Sun Cluster
• L’idée de base de Sun Cluster est simple : deux machines banalisées en
tandem se partagent (au moins) une adresse IP de « service » (figure 10).
Ce n’est l’adresse réelle d’aucune des deux machines, mais une adresse
virtuelle qui peut bouger de l’une à l’autre au besoin, et en particulier en
cas de défaillance de l’une d’elles. Les deux machines se surveillent
mutuellement pour savoir quand reprendre l’adresse de la machine
défaillante et déclencher des actions correctives. Sun Microsystems a
raffiné le mécanisme pour que plusieurs adresses puissent migrer dans
des configurations plus complexes ; on se bornera ici au cas le plus simple.
Dans les faits, les clusters vendus par Sun sont composés de serveurs de
milieu ou haut de gamme dans lesquels beaucoup de composants sont
répliqués (les interfaces réseaux, les interfaces disques, les alimentations,
les disques en RAID...), ce qui diminue les risques de pannes de chaque
nœud du serveur. L’installation et l’administration n’en sont pas
particulièrement aisées (une station d’administration dédiée, un
concentrateur de ports série, des logiciels et des outils d’administration
spécifiques...).
• Ce type de configuration n’est pas adapté à toutes les applications.
Concrètement, deux problèmes peuvent se présenter :
• la migration de l’adresse IP fait tomber toutes les connexions TCP et est donc
visible depuis l’extérieur ;
• l’état des applications doit être (à peu près) synchrone (ou inexistant), faute
de quoi des incohérences peuvent être visibles de l’extérieur.
• Les applications qui ne sont pas basées sur TCP et qui sont sans état peuvent
continuer à fonctionner à condition que les logiciels serveurs partagent une
configuration commune. Dans cette catégorie, on peut compter NFS (Network
File System ), système de fichiers partagés en réseau, basé sur UDP (User
Datagram Protocol ) et complètement sans état. Dans une certaine mesure,
les serveurs HTTP (HyperText Transfer Protocol ) simples rentrent aussi dans
cette catégorie puisque leur état se trouve dans des fichiers partagés par NFS
et qu’ils ne conservent pas d’informations sur les sessions TCP (chaque
requête est une nouvelle connexion).
• Les applications reposant sur TCP doivent par contre être capables de tolérer
les pertes de connexion en restaurant la session TCP, ce qui impose cette
condition aussi bien au client qu’au serveur et est donc toujours perceptible à
l’extérieur.
• Les applications qui ont un état devant rester cohérent d’une requête à
l’autre doivent être synchronisées entre les différents nœuds du cluster. Cela
reste un mécanisme interne commun aux deux nœuds dont le seul impact
perceptible à l’extérieur peut tenir à une baisse de performance due à la
synchronisation ou à des incohérences limitées. Ces deux dernières conditions
ne sont pas faciles à remplir et demandent une modification du code source
des applications. C’est pour cette raison qu’au début des Sun Clusters, Oracle
fournissait une version spécifique de sa base de données amirale.
• Il existe des implémentations très proches de Sun Cluster sous Linux, comme
la solution FailSafe de SGI et Piranha (RHHAS dans sa version commercialisée
par RedHat).

• 3.2 Tolérance aux fautes dans CORBA

• CORBA (Common Object Request Broker Architecture )  est un modèle
d’invocation d’objets auquel est associé une série de services de support. Son
succès s’est un peu affaibli, notamment du fait de la concurrence plus
commerciale que technique de .NET, mais il demeure très utilisé dans des
domaines critiques comme la défense ou les Télécoms.
• En 1998, la spécification Fault Tolerant CORBA (FT CORBA) a été proposée
comme standard par l’OMG pour laquelle il existe plusieurs réalisations
commerciales (ORBexpress  et FTORB ).
• Cette spécification est le résultat de compromis entre différents acteurs aux
objectifs différents : d’une part des industriels désireux d’offrir ou d’utiliser
une solution simple et robuste, et d’autre part des chercheurs avec des
solutions innovantes à proposer. C’est pourquoi la spécification propose
plusieurs niveaux de fonctionnalités et est applicable aussi bien à des
systèmes à petite qu’à grande échelle.
• Dans CORBA, les entités exécutables sont des objets désignés par des
références (IOR Interoperable Objet Reference). L’invocation d’une opération
sur une référence conduit à l’exécution de cette opération sur l’objet cible
(en général situé sur une autre machine). La tolérance aux fautes CORBA se
base sur la redondance transparente des objets, la détection des fautes et la
reprise sur défaillance. Dans ce but, elle introduit trois nouveautés : une
référence de groupe (IOGR) qui désigne plusieurs objets liés par une relation
de coopération, un service de détection et de notification de faute, et un
gestionnaire de réplication associé à des mécanismes de coopération entre
objets.
• Deux contraintes dérivées du modèle CORBA sont respectées :
• l’interopérabilité avec un ORB (Object Request Broker ) classique : un ORB qui
n’implémente pas la tolérance aux fautes CORBA peut invoquer un objet
tolérant aux fautes (mais avec des limitations) ;
• la sémantique CORBA : les invocations respectent le modèle d’objet CORBA et la
sémantique « au plus une fois » (une requête n’est effectivement traitée qu’au
plus une fois).
• Il est à noter que certaines limitations s’appliquent :
• la cohérence forte entre les répliques d’un même objet demande un
comportement déterministe de la part des applications ;
• des répliques d’un même objet doivent être créées sur un ORB du même
vendeur, cela pour ne pas avoir à concevoir un protocole interopérable entre les
répliques ;
• l’infrastructure ne résout pas les fautes de partition de réseau, ni le mauvais
fonctionnement des objets ou les fautes par corrélation ;
• seule la communication à travers CORBA est prise en compte par la tolérance
aux fautes. En revanche, elle l’est de manière complète, c’est-à-dire que des
invocations de clients répliqués vers des serveurs répliqués respectent la
sémantique au plus une fois.
• La réplication peut être prise en charge soit par l’application, soit par
l’infrastructure supportant FT CORBA. Le mode applicatif permet à une
application d’utiliser par exemple un système de base de données pour
toutes les fonctions de création des objets ou de sauvegarde d’état.
• Il y a cinq modes de réplication possibles qui obéissent au même
fonctionnement général :
• sans état : un objet qui ne modifie pas son état et n’a pas besoin de le
sauvegarder ;
• la réplication passive froide : après la fin d’une opération, on enregistre l’état
de l’objet, et les messages reçus sont journalisés. Après une faute, l’objet
redémarre à partir de l’état stocké et on rejoue les messages journalisés ;
• la réplication passive chaude : similaire à la précédente, sauf que l’état est
envoyé aux répliques ;
• la réplication active : tous les objets exécutent les opérations simultanément,
un mécanisme de diffusion fiable, ordonné et atomique étant nécessaire ;
• la réplication active avec vote : similaire à la réplication active mais un vote
prend place après chaque opération dont l’issue détermine l’état final.
• Une particularité de la réplication active est que, lorsque des objets
répliqués envoient des invocations vers d’autres objets, plusieurs
invocations sont reçues par ces derniers, ce qui viole la sémantique au
plus une fois. Un mécanisme est donc fourni qui permet le filtrage des
messages émis à partir d’un groupe de serveurs répliqués (filtrage par le
groupe source) qui assure le respect de la contrainte.

• Les principaux composants de l’architecture sont les suivants (figure 11) :

• le service de détection de fautes. Il est largement configurable et permet

de surveiller le bon fonctionnement des processeurs comme des objets. Il
est composé de plusieurs sous-composants (en général eux-mêmes
répliqués pour ne pas être eux-mêmes sensibles aux fautes) : les
détecteurs de fautes qui interrogent directement les objets, l’analyseur et
le notificateur de fautes qui centralisent et font la corrélation entre les
indications des détecteurs pour les synthétiser en des notifications qui
sont envoyées au gestionnaire de réplication ;
• le service de gestion de réplication, qui se charge de la création des
objets, de la création et de la gestion des groupes et de leurs références,
de l’activation des objets dans le cas de la réplication passive ;

les composants fabriques (F) qui créent les objets au sein des sites
serveurs sur instruction du service de réplication ;

• les composants de journalisation (J) et de redémarrage (R), intégrés dans

la partie serveur de l’ORB tolérant aux fautes ;

• un service de propriétés, qui enregistre toutes les caractéristiques liées à

un groupe (style de réplication, nombre de répliques...).
Figure 11 - Architecture FT-CORBA
• Quand l’application désire créer un objet, elle exécute une requête vers le
service de réplication, qui la relaie vers le nombre de fabriques nécessaire pour
satisfaire les contraintes du groupe. Elle reçoit une référence de groupe (IOGR
Interoperable Objet Group Reference) qu’elle peut transmettre à des clients. Les
clients invoquent les serveurs à travers l’IOGR de manière transparente, et les
serveurs coordonnent leur état entre eux suivant le mode de réplication. En cas
de défaillance, les clients ont toujours accès au service soit par commutation,
soit grâce à la diffusion. Le redémarrage des serveurs est coordonné par le
service de réplication et invisible au client comme à l’application.
• La norme possède deux niveaux de conformité, l’un pour la tolérance passive,
l’autre pour la tolérance active. Les mécanismes en cause dans la tolérance
active sont plus complexes et certaines entreprises utilisatrices ne sont
intéressées que par la partie passive dont la réalisation est plus simple et les
applications industrielles plus directes.
• La tolérance aux fautes de CORBA définit des interfaces et des mécanismes
généraux, mais toute la complexité et la performance se cachent dans la
réalisation de ces interfaces et de ces mécanismes. Il existe aujourd’hui au
moins deux réalisations commerciales (ORBexpress  et FTORB ) dont les
performances sont différentes.
• 3.3 RSERPOOL
• RSERPOOL (Reliable Server Pooling ) est un groupe de l’IETF formé pour
définir une norme de tolérance aux fautes associées aux réseaux IP. Le
groupe ayant commencé ses travaux en 1998, il n’existe pas de réalisation
commerciale à ce jour bien que des versions de test soient disponibles
(notamment http://www.sctp.de). Le groupe a cependant produit une
importante série de projets de normes  qui forment un ensemble
cohérent et qui devraient aboutir à la normalisation et à des produits
commerciaux.
• L’approche n’est pas conceptuellement très différente de la précédente,
mais elle se place directement au niveau réseau. Elle est en revanche
moins sophistiquée puisqu’elle se limite à la fourniture des moyens
d’accès à des serveurs répliqués, et ne concerne pas la manière dont ils
sont effectivement répliqués ou aux propriétés de la communication.
Cependant, la possibilité de faire du partage de charge au sein d’un
groupe est prévue. RSERPOOL fournit ainsi les moyens de fiabiliser des
services sur l’Internet de manière simple et robuste, même si ce n’est pas
de manière transparente.
• La tolérance aux fautes est obtenue par la réplication des serveurs au sein d’un
groupe (pool ). La relation entre client et serveur (respectivement PU pour Pool
User et PE pour Pool Element ) se fait au travers d’un protocole défini par
l’application qui peut choisir entre SCTP (Stream Control Transmission Protocol ),
une surcouche au-dessus de TCP (correspondant à un TCP orienté message et
enrichi d’une couche de retransmission et de détection de faute supplémentaire)
ou même UDP. Un service de nom particulier permet à un client d’avoir accès à
l’un des membres du groupe.
• RSERPOOL permet un certain nombre de variantes plus ou moins sophistiquées à
partir de quelques éléments de base : l’existence du service de nom, les
protocoles ASAP (Agregate Server Access Protocol ) et ENRP (Endpoint Name
Resolution Protocol ).
• Le serveur de nom est l’élément central de l’architecture. C’est à lui que les
clients s’adressent pour obtenir la référence d’un serveur correspondant à leur
requête. Les serveurs de noms peuvent être répliqués pour la tolérance aux
fautes comme pour la montée en charge ; ils communiquent entre eux à travers
le protocole ENRP.
• L’architecture RSERPOOL prévoit que des clients qui n’en ont aucune
connaissance puissent utiliser ses services au travers d’une passerelle, mais celle-
ci peut elle-même constituer un point de défaillance.
• 3.3.1 Profil minimal

• Le profil minimal a recours au seul service de nom, l’interaction entre

client et serveur se faisant par TCP, UDP ou SCTP au choix de l’application,
mais sans commutation transparente vers un nouveau serveur (figure 12).
Un client doit contacter un serveur de nom à l’aide du protocole ENRP en
lui transmettant le nom du service, et récupère l’adresse, le protocole et
le port sur lequel il contactera le serveur choisi. Les serveurs
s’enregistrent auprès du service de nommage également à l’aide du
protocole ENRP (ce n’est pas le rôle premier de ENRP, mais cela simplifie
la réalisation). Dans ce cas, c’est donc le serveur de nom qui réalise la
politique éventuelle de partage de charge entre les éléments d’un même
groupe.
Figure 12 - Architecture RSERPOOL avec profil minimal
• 3.3.2 Profil complet

• Le profil complet utilise le protocole ASAP pour la communication entre

les clients et le service de nom, et entre les serveurs et le service de nom
(figure 13). ASAP permet l’adressage d’un service par nom et pas par
adresse IP. Il introduit également un canal de contrôle dans la
communication entre client et serveur. Sur ce canal de contrôle, le
serveur peut faire parvenir au client un testament, une indication du
serveur à contacter en cas de disparition de celui-ci, et un biscuit (cookie
en anglais) qui contient des données opaques pour aider le nouveau
serveur à rétablir le contexte du service avec ce client.
Figure 13 - Architecture RSERPOOL avec profil complet
• ASAP permet au service de nom comme au client de vérifier
périodiquement l’état des serveurs. Il réalise également la politique de
partage de charge entre les serveurs.
• Dans le cas où l’on n’utilise pas SCTP et ses destinations multiples, la
retransmission des messages en cas de passage d’un serveur à l’autre est
à la charge de l’application. De même, dans le cas où l’on utilise TCP, le
rétablissement des relations entre client et serveur est à la charge de
l’application, ASAP fournissant les informations nécessaires.
4. Une étude de cas : un routeur Internet
•  4.1 Tolérance aux fautes dans un routeur

4.2 Tolérance aux fautes des applications de

routage

4.2.1 OSPF , RIP

4.2.2 BGP

4.2.3 Bilan
• Beaucoup d’applications critiques ont des besoins de tolérance aux fautes,
parfois en compétition avec leur mission (souvent pour des raisons de
performance). C’est le cas en particulier des applications de
télécommunications qui doivent répondre à des contraintes de disponibilité
draconiennes (99,999 %) qui font maintenant partie des exigences de base
des opérateurs, quand ce ne sont pas tout simplement les contraintes
réglementaires comme pour le téléphone. Pour cette raison, la tolérance
aux fautes a toujours été au cœur de la réalisation des équipements et
occupe une place considérable ; on estime que la moitié du logiciel d’un
commutateur est consacré au traitement des erreurs et des fautes.
• Le domaine des réseaux IP (Internet Protocol ) n’a pas suivi ce chemin
pendant longtemps car son modèle même suppose que les routeurs sont
faillibles et prévoit les moyens de les contourner. À mesure que les réseaux
IP se sont développés et qu’ils sont devenus commerciaux, les
investissements supplémentaires requis par cette approche (ou les
défaillances causées par l’absence de redondance) et la complexité induite
sont devenus difficiles à justifier. Aujourd’hui, la première exigence des
opérateurs de réseaux IP est la fiabilité et la disponibilité.
• À la fin des années 1990, la plupart des grands fabricants de routeurs ont
intensifié les efforts sur la tolérance aux fautes de leurs équipements.
Jusque-là, la tolérance aux fautes se résumait au redémarrage plus ou
moins rapide des logiciels de contrôle (on fait ici abstraction de la
tolérance aux fautes matérielles pour laquelle de nombreuses solutions
existent sur le marché). Il faut dire que, jusque dans les années 1996-
1997, les routeurs restaient principalement des ordinateurs dotés de
plusieurs interfaces réseau. Difficile de pallier les défaillances de
composants critiques comme la mémoire ou le processeur. Après cette
date ont commencé à apparaître des processeurs spécialisés dans le
traitement des paquets et des commutateurs internes décentralisés et
tolérants aux fautes. Dans le même temps, les fonctions de contrôle ont
été déportées sur une carte processeur autonome. Ces architectures
composées de blocs indépendants se prêtent beaucoup mieux à la
fiabilisation, notamment lorsque l’on double les cartes de contrôle.
• Revenons un instant sur ce que l’on désigne par fonctions de contrôle.
• Dans un réseau IP, ce sont principalement (et pour le moment) celles liées à
l’établissement des tables de routage. Plusieurs composants logiciels sont
consacrés à cette tâche : l’un est spécialisé dans le routage au sein d’un
domaine restreint (désigné IGP, Interior Gatewey Protocol ) et fait appel aux
protocoles OSPF (Open Shortest Path First ), RIP (Routing Information
Protocol ) ou IS-IS (Intermediate System to Intermediate System ), l’autre
dans le routage entre domaines (désigné EGP, Exterior Gateway Protocol )
dont le seul représentant largement utilisé est le protocole BGP (Border
Gateway Protocol ). Ces composants sont divisés en deux : une partie se
charge du calcul du chemin le plus court dans le graphe des routeurs, l’autre
d’établir la topologie de ce graphe par la communication entre pairs sur les
routeurs voisins. Ces logiciels ne sont donc pas des processus de calcul pur
et la communication avec l’extérieur y joue un rôle majeur, ce qui constitue
une difficulté particulière pour leur fiabilisation.
• Une contrainte supplémentaire provient du fait que les réseaux sont
hétérogènes : un routeur doit pouvoir cohabiter avec un routeur fabriqué
par un autre équipementier ou avec des équipements plus anciens. La
tolérance aux fautes ne peut donc reposer sur des conventions mutuelles
dans les protocoles de communication, elle doit être transparente.
• On voit bien qu’ici, l’apport des modèles de tolérance aux fautes abordés
dans le paragraphe 3 est insuffisant : la sécurisation des communications
(au sens réseau IP) est indispensable. De plus, des contraintes
opérationnelles ou de développement interdisent parfois l’usage de ces
approches (au moins pour le moment) et font que des développements
ad hoc sont le plus souvent utilisés. Deux contraintes rendent ici cela
inévitable : le besoin d’interopérer avec les voisins (ce qui interdit de
changer de protocole de communication) et le fait que les applications de
routage sont développées à partir de bases existantes du fait de leur
complexité (ce qui rend difficile les modifications importantes, en
particulier quand on doit permettre des modifications ultérieures).
Figure 14 - Architecture matérielle d’un routeur
• 4.1 Tolérance aux fautes dans un routeur
• Pour pallier les défaillances matérielles, les gros routeurs dupliquent tous les
composants essentiels et en particulier les calculateurs de contrôle sur
lesquels tournent les applications de routage (figure 14). Nous ne discuterons
pas de la tolérance aux fautes des autres composants qui relève de stratégies
différentes. Ces calculateurs fonctionnent en général sur le mode de la
réplication semi- passive, le plus répandu dans le monde des Télécoms. La
réplication purement passive imposerait des temps de commutation trop
longs et n’est donc pas considérée. En réplication semi-passive, le système
comme les applications sont démarrés mais dans un état d’attente.
• Le support système de ces processeurs prend en général en charge la
détection de faute et la commutation d’un calculateur vers l’autre.
• La détection de faute doit être aussi rapide et précise que possible pour
limiter le temps d’indisponibilité et éviter les fausses détections. Pour cette
raison, elle est souvent faite à l’aide de moyens matériels dédiés : une ligne
de communication particulière sur laquelle transite régulièrement une
information qui témoigne de la bonne santé des processeurs.
• Cela n’est pas toujours suffisant et il peut être nécessaire d’ajouter des
mécanismes de détection de faute au niveau applicatif, qui surveillent le bon
état d’une application et provoquent une commutation au besoin.
• La commutation d’un processeur à l’autre permet de simplifier leur interaction :
le processeur montant doit reprendre toutes les fonctions du processeur
descendant qui doit les abandonner (même s’il n’est pas entièrement hors d’état
de fonctionner) et laisser la place libre pour éviter les interactions malheureuses.
Reprendre les fonctions impose que chacun des éléments logiciels existants ait
au préalable transféré une partie de son état d’un processeur à l’autre. Dans le
cas de la pile IP, il s’agit des paramètres de configuration et en particulier de son
adresse, IP en soi étant à peu près sans état.
• Par ailleurs, il arrive que l’on provoque des commutations en l’absence de faute,
par exemple pour des raisons de maintenance comme pour changer la version
des logiciels.

• 4.2 Tolérance aux fautes des applications de routage

• Revenons sur les protocoles de routage présents sur un routeur et sur leurs
besoins de fiabilisation.
• 4.2.1 OSPF , RIP
• OSPF et RIP utilisent UDP pour communiquer avec leurs voisins. UDP est
un protocole datagramme qui n’offre aucune notion de connexion ni de
fiabilité dans la transmission des paquets. Ces caractéristiques font que
les applications prennent en compte les défaillances de communication à
leur niveau, en particulier en utilisant des machines à états complexes
permettant de gérer la perte des messages. Ces applications sont
cycliques : elles collectent des informations sur la topologie du graphe des
routeurs, puis lancent un calcul de plus court chemin dans le graphe.
• La fiabilisation de ces applications demande de copier une part
significative de leur état de l’active à la suppléante. On doit repérer dans
l’application des points (points de reprise) auxquels l’état est cohérent
(pas en cours de modification) et à partir desquels on pourra permettre la
reprise de l’exécution (ce qui est aisé dans une application cyclique). La
pose des points de reprise doit être faite en fonction des besoins de
l’application : plus on pose de points de reprise, plus l’application
redémarrera dans un état proche de la précédente, plus l’application
devra être modifiée et plus le coût en performance sera élevé.
• Lors de la copie de l’état, un minimum de vérifications sur leur cohérence
interne (structurelle ou même sémantique) est effectué pour limiter la
propagation des erreurs d’un processeur sur l’autre et ainsi limiter le
risque de fautes communes.

• 4.2.2 BGP
• En revanche, BGP communique avec ses pairs par TCP , un protocole
orienté connexion qui en détecte les ruptures. Ruptures dont BGP tire des
conclusions sur la santé de ses pairs, et qui ont donc des conséquences
considérables sur les tables de routage, en particulier une fois transmises
à travers l’Internet tout entier . En outre, TCP est un protocole en flux, qui
ne connaît pas de délimitation de message explicite au niveau applicatif,
ce qu’observe l’application n’est donc pas directement corrélé aux
messages reçus dans la pile de protocole (ce qui fait que l’application ne
retrouve pas les limites de messages qu’elle attend). Ces deux problèmes
sont relativement disjoints et peuvent être traités séparément : une partie
protocolaire et une partie applicative.
• La stratégie de fiabilisation est similaire aux précédentes mais il faut y ajouter
la fiabilisation des connexions TCP avec les voisins, un développement
récent qui a été effectué spécifiquement pour ce type d’applications.
• L’objectif de la face protocolaire est de pouvoir transférer une connexion TCP
d’un processeur à l’autre sans que l’autre extrémité s’en aperçoive. Pour
cela, on utilise les propriétés du protocole IP et on détermine les
informations que l’on doit transmettre d’une pile à l’autre et quand elles
doivent être transmises. TCP détecte la perte d’une connexion quand il reçoit
une réponse lui indiquant qu’un de ses messages de contrôle (demande de
réémission ou acquiescement) n’est pas compris par le destinataire, les
paramètres d’identification de connexion étant invalides (l’expiration du délai
de garde TCP ne nous concerne pas car il est trop long pour être observé dans
ce cadre). Pour éviter cela, il suffit que la pile montante possède les
informations de la pile descendante concernant les connexions. La pose des
points de reprise (où l’on synchronise les deux piles) n’est pas faite en
fonction de l’application mais en fonction des messages transitant sur le
réseau. Les propriétés de IP permettent qu’un message émis ne soit jamais
reçu ou qu’il soit reçu plusieurs fois : cela ne perturbe pas le fonctionnement
de TCP et permet de limiter le nombre de points de reprise posés.
• Pour une connexion donnée, la synchronisation doit être faite : lorsque la
connexion est créée ou fermée, lorsque l’on émet un fragment ou un
acquiescement (un message reçu doit avoir été émis). L’état à transférer
au moment de ce point de reprise consiste dans les blocs de contrôle TCP
associés à la connexion, ajouté des blocs de contrôle Internet à la création
(figure 15).
Figure 15 - Fiabilisation de la face protocolaire de BGP
• La face applicative a pour rôle de s’assurer que l’application montante lira au
même point que dans le flux TCP, ce qui est cohérent avec le point de reprise.
Le point de reprise de cette face est donc synchronisé avec celui de
l’application (un point de reprise de l’application doit entraîner un point de
reprise de la face applicative). L’état à transférer au moment de ce point de
reprise se limite à la position dans le flux.

• 4.2.3 Bilan
• La plupart des grands routeurs Internet supportent aujourd’hui ce type de
fonctionnalité qui est devenu indispensable pour obtenir l’assentiment des
opérateurs de télécommunications dont la fiabilité est maintenant la
première préoccupation.
• Les réalisations de ces mécanismes demeurent cependant peu documentées
hors de leurs caractéristiques diffusées pour des raisons de marketing. Les
performances de ces solutions s’avèrent suffisantes pour qu’aucune
dégradation n’ait été notée après leur introduction. La compétition entre
équipementiers sur la performance en terme de nombre de routes acceptées
reste un facteur de choix pour certains opérateurs.
• 5. Conclusion
•  Dans cet article, nous avons choisi d’aborder la sûreté de fonctionnement
des applications en réseau sous un angle pratique. Après une présentation
des concepts de la sûreté de fonctionnement des systèmes informatiques
et de l’un des moyens les plus répandus pour la mettre en œuvre, à savoir
la tolérance aux fautes, nous avons donné un panorama des techniques
pouvant être employées en mettant l’accent sur les particularités des
systèmes répartis montrant la complexité du développement
d’applications en réseau tolérantes aux fautes.
• Après une rapide présentation des solutions propriétaires fournies
aujourd’hui par les constructeurs informatiques, nous avons ensuite
souligné que des efforts de normalisation ont été faits par l’OMG pour la
tolérance aux fautes des applications à base d’objets distribués. Les
spécifications et les concepts proposés dans la norme FT CORBA sont
publics  et peuvent donc être suivis par les éditeurs de logiciels support
désireux de développer des systèmes sûrs y compris en dehors du monde
CORBA.
• De même, dans le domaine des applications Internet, le groupe de travail
de l’IETF RSERPOOL est très actif et a produit une importante série de
projets de standards qui forment un ensemble cohérent et qui devraient
aboutir à la normalisation et à des produits commerciaux dans les
prochaines années.
• Nous avons terminé par la présentation de la problématique et de
certaines solutions pour la sûreté de fonctionnement d’un routeur
Internet. Cela montre bien l’importance croissante de cette discipline et
son impact stratégique du point de vue des équipementiers de
télécommunications.