Présentation
Auteur(s)
-
René J. CHEVANCE : Ingénieur du Conservatoire national des arts et métiers - Docteur ès sciences - Conseiller Technologie et Partenariats Bull - Professeur associé au CNAM
Lire cet article issu d'une ressource documentaire complète, actualisée et validée par des comités scientifiques.
Lire l’articleINTRODUCTION
De plus en plus les activités sont dépendantes de ressources informatiques. La disponibilité de ces ressources informatiques, c’est-à-dire leur capacité à assurer le service spécifié et le degré de confiance que l’utilisateur peut accorder aux services rendus par les systèmes informatiques sont devenus des exigences des utilisateurs et donc des propriétés essentielles de ces systèmes.
Les systèmes informatiques étant sujets aux défaillances, les concepteurs de ces systèmes ont recherché les moyens de pallier ces défaillances.
Le concept de sûreté de fonctionnement est né au cours des années 1980 pour caractériser ce besoin. La sûreté de fonctionnement d’un système est la propriété qui permet à un utilisateur de placer une confiance justifiée dans le service que ce système délivre. C’est la propriété et les caractéristiques d’une entité ayant rapport au temps qui lui confère l’aptitude à satisfaire les besoins exprimés ou implicites pour un intervalle de temps donné et des conditions d’emploi fixées (X 50-125, norme de management de la qualité et de l’assurance de la qualité, standard ISO 8402). C’est l’ensemble des aptitudes d’un produit lui permettant de disposer des performances fonctionnelles spécifiées, au moment voulu, pendant la durée prévue, sans dommage pour lui-même et pour son environnement.
On appelle critique une fonction d’un système ou d’un sous-système pour laquelle la propriété de sûreté de fonctionnement est une contrainte stricte. En d’autres termes, un défaut de fonctionnement peut entraîner la perte de la mission ou des dommages inadmissibles sur le système ou son environnement.
Dans l’article Systèmes à haute disponibilité- Solutions sont exposées les solutions proposées par les constructeurs de systèmes informatiques et les fournisseurs de systèmes d’exploitation.
Il convient de noter que toutes les marques citées dans cet article sont la propriété de leurs titulaires respectifs.
DOI (Digital Object Identifier)
Cet article fait partie de l’offre
Technologies logicielles Architectures des systèmes
(239 articles en ce moment)
Cette offre vous donne accès à :
Une base complète d’articles
Actualisée et enrichie d’articles validés par nos comités scientifiques
Des services
Un ensemble d'outils exclusifs en complément des ressources
Un Parcours Pratique
Opérationnel et didactique, pour garantir l'acquisition des compétences transverses
Doc & Quiz
Des articles interactifs avec des quiz, pour une lecture constructive
Présentation
3. Principes de conception et introduction aux solutions
Dans ce chapitre, les principes de conception des systèmes à haute disponibilité sont passés en revue et on examine ensuite les différentes options d’architecture pour les systèmes à haute disponibilité. La description de ces différentes solutions est l’objet de l’article suivant [Systèmes à haute disponibilité- Solutions, § 1 et 2].
3.1 Concept d’état d’un système
D’un point externe (c’est-à-dire visible des utilisateurs du système), un système à haute disponibilité doit masquer les défaillances auxquelles il est sujet, vis-à-vis de son environnement (c’est le critère de transparence). Sous cette hypothèse, un système, suite à une défaillance, doit continuer les opérations à partir d’un état défini. Pour ce faire, deux situations sont possibles :
-
le système maintient en permanence plusieurs versions de l’état courant du système et, en cas de défaillance, continue l’exécution à partir de l’un des états courants disponibles ;
-
le système maintient des états à partir desquels le traitement peut être repris. On se trouve dans une situation où des points de reprise sont définis soit de façon explicite (c’est ce que l’on verra avec les systèmes pour lesquels la reprise est fondée sur un schéma de type transactionnel), soit de façon implicite (fait au niveau le plus fin de l’architecture). C’est une technique que l’on appelle technique des points de reprise.
La situation dans laquelle le traitement en cours est abandonné et où le système est réinitialisé ne répond pas au critère de transparence.
À l’évidence, la solution qui consiste à maintenir en permanence plusieurs contextes passe...
Cet article fait partie de l’offre
Technologies logicielles Architectures des systèmes
(239 articles en ce moment)
Cette offre vous donne accès à :
Une base complète d’articles
Actualisée et enrichie d’articles validés par nos comités scientifiques
Des services
Un ensemble d'outils exclusifs en complément des ressources
Un Parcours Pratique
Opérationnel et didactique, pour garantir l'acquisition des compétences transverses
Doc & Quiz
Des articles interactifs avec des quiz, pour une lecture constructive
Principes de conception et introduction aux solutions
Cet article fait partie de l’offre
Technologies logicielles Architectures des systèmes
(239 articles en ce moment)
Cette offre vous donne accès à :
Une base complète d’articles
Actualisée et enrichie d’articles validés par nos comités scientifiques
Des services
Un ensemble d'outils exclusifs en complément des ressources
Un Parcours Pratique
Opérationnel et didactique, pour garantir l'acquisition des compétences transverses
Doc & Quiz
Des articles interactifs avec des quiz, pour une lecture constructive