Sûreté de fonctionnement des applications en réseau : Une étude de cas : un routeur Internet

1.1 - Attributs de la sûreté de fonctionnement

Figure 2 - Fiabilité Figure 3 - Sécurité-innocuité Figure 4 - Disponibilité Figure 5 - Maintenabilité
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.3 - Tolérance aux fautes de communications
2.4 - Techniques pour les systèmes répartis

3 - Approches pratiques

3.1 - Architectures en grappe
3.2 - Tolérance aux fautes dans CORBA

Figure 11 - Architecture FT-CORBA
3.3 - RSERPOOL

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

5 - Conclusion

Présentation

Auteur(s)

Sophie CHABRIDON : Maître de conférences à l’Institut National des Télécommunications (GET/INT), Évry
Julien MAISONNEUVE : Coordinateur Standards ISR, Alcatel Research & Innovation, Marcoussis
François SIMON : Directeur scientifique adjoint de l’Institut National des Télécommunications (GET/INT), Évry

Lire cet article issu d'une ressource documentaire complète, actualisée et validée par des comités scientifiques.

Lire l’article

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.

Cet article est réservé aux abonnés.
Il vous reste 95 % à découvrir.

Pour explorer cet article Consulter l'extrait gratuit

Déjà abonné ? Se connecter

DOI (Digital Object Identifier)

https://doi.org/10.51257/a-v1-h5850

Lecture en cours
Présentation

Page
suivante

Conclusion

Article inclus dans l'offre

"Sécurité des systèmes d'information"

(80 articles)

Une base complète d’articles

Actualisée et enrichie d’articles validés par nos comités scientifiques.

Des contenus enrichis

Quiz, médias, tableaux, formules, vidéos, etc.

Des modules pratiques

Opérationnels et didactiques, pour garantir l'acquisition des compétences transverses.

Des avantages inclus

Un ensemble de services exclusifs en complément des ressources.

Voir l'offre

4. Une étude de cas : un routeur Internet

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...

Cet article est réservé aux abonnés.
Il vous reste 94 % à découvrir.

Pour explorer cet article Consulter l'extrait gratuit

Déjà abonné ? Se connecter

Lecture en cours
Une étude de cas : un routeur Internet