Systèmes à haute

disponibilité :
Définitions et solutions

Octobre 2001
René J. Chevance

Contenu
L’objectif de cette présentation est d’introduire les définitions propres aux systèmes à haute disponibilité
et de présenter ensuite des solutions utilisées dans le cadre de serveurs pour des systèmes d’information

Définitions

Sûreté de fonctionnement

Coût de l’indisponibilité

Classification des systèmes

Concepts et terminologie

Modes de défaillance

Grandeurs caractéristiques

Analyse des causes des défaillances

Principes de conception

Solutions

Solutions au niveau du matériel

Solutions au niveau du logiciel

Recouvrement après catastrophe

Estimation de la disponibilité des systèmes

Comparaison des solutions

Perspectives
Page 2

© RJ Chevance

Page 1
 Définitions

Page 3

© RJ Chevance

Sûreté de fonctionnement

Notion de sûreté de fonctionnement

Propriété qui permet à un utilisateur de placer une
confiance justifiée dans le service que le système
délivre

C’est la propriété et les caractéristiques d’une entité
ayant rapport au temps qui lui confèrent l’aptitude à
satisfaire les besoins exprimés ou implicites pour un
intervalle de temps donné et des conditions d’emploi
fixées (X50-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
Page 4

© RJ Chevance
pour son environnement

Page 2
 Définitions(2)

 Propriétés liées à la sûreté de fonctionnement

Fiabilité (reliability). Correspond à la continuité du service
rendu.

Disponibilité (availability). Correspond à l’aptitude du
système à être prêt à rendre le service pour lequel il a été
conçu.

Maintenabilité (maintenability). C’est l’aptitude d’un
système à être maintenu en condition opérationnelle.

Innocuité (safety), ou encore sécurité vis-à-vis de
l’environnement.

Immunité (immunity). Correspond à la résistance d’un
système aux agressions externes.
Pour les systèmes informatiques, l’immunité correspond
aux 3 critères suivants : disponibilité du système, intégrité
et confidentialité des données.

Page 5

© RJ Chevance

Coût de l’indisponibilité

Coût moyen d’une heure d’indisponibilité

du système (Source Contingency Planning Research)

Application Secteur d’activité Coût de l’indisponibilité

Courtage Finance $6,45 millions
Ventes par carte de paiement Finance $2,6 millions
Films à la demande Loisirs $150 000
Téléachat Distribution $113 000
Ventes sur catalogue Distribution $90 000
Réservation aérienne Transport $89 500

Page 6

© RJ Chevance

Page 3
 Classification des systèmes
 D’après [GRA91], classification des systèmes en
fonction de leur disponibilité

Hypothèse 7 jours sur 7, 24 heures sur 24 (7x7, 24x24)

Attention, la terminologie peut varier, il convient de s’en
tenir aux chiffres

Type de système Indisponibilité Disponibilité Classe de

(minutes par (%) disponibilité
an)
Non géré (Unmanaged) 50000 90 1
Géré (Managed) 5000 99 2
Bien géré (Well Managed) 500 99,9 3
Tolérant les fautes (Fault-tolerant) 50 99,99 4
Haute disponibilité (High Availability) 5 99,999 5
Très haute disponibilité (Very High Availability) 0,5 99,9999 6
Ultra haute disponibilité (Ultra High Availability) 0,05 99,99999 7

Page 7

© RJ Chevance

Concepts et terminologie
 Concept de service (Source Bull)
Défaillance complète

Défaillance partielle
Défaillance partielle Défaillance complète

Service Service Service

rendu dégradé non rendu

Restauration complète Restauration partielle

Restauration partielle
Restauration complète

 Terminologie
Activation du défaut
Système

Faute Défaut Erreur Défaillance

(Erreur latente) (Effective)

Types de défauts

Bhorbug : un ré-essai conduit à une erreur

Heisenbug : un ré-essai ne conduit pas systématiquement
Page 8 à une erreur
© RJ Chevance

Page 4
 Modes de défaillance
 Défaillance = non conformité de la réponse d’un
système par rapport à ses spécifications. La
réponse d ’un système : est fonction de l’état du
système, doit être fournie dans un intervalle de
temps, le système doit se trouver dans un état
spécifié, les valeurs fournies doivent correspondre
aux spécifications.
 Modes de défaillance

Défaillance par omission (Omission Failure)

Défaillance temporelle (Timing Failure)

Défaillance de réponse (Response Failure)

Valeur fournie (Value Failure)

État résultant (StateTransition Failure)

Défaillance de type «plantage» (Crash Failure)
Page 9

© RJ Chevance

Grandeurs caractéristiques
 Il s’agit de grandeurs accessibles et mesurables (comme toute
mesure, elles doivent vérifier les propriétés suivantes :
représentativité, interprétables, fidèles, précises et utiles).
 Mesures liées au concept de défaillance
 MTTF, ou Temps moyen jusqu’à défaillance (Mean Time To
Failure)
 MTBF, ou Temps moyen entre défaillances (Mean Time Between
Failures)
 Note : si pas de redondance MTBF = MTTF + MTTRes
 Mesures liées au concept de maintenabilité
 MTTRes, ou Temps moyen jusqu’à restauration (Mean Time To
Restore ou Mean Time to Recover)
 MTTRep, ou Temps moyen jusqu’à réparation (élément) (Mean
Time To Repair element)
 Mesure liée au concept de disponibilité
 At = MTTF/(MTTF+MTTRes)
Page 10

© RJ Chevance

Page 5
 Analyse des causes des défaillances
 Peu de données publiées. Tandem a publié, à deux
reprises (1985 et 1989) [GRA90], des données
observées sur ses systèmes en clientèle.
Défaillances/1000 système an
en fonction de la cause première % des défaillances par cause première
120 100
90
100
80
70

Pourcentage
80
Défaiillances

60
60 50
40
40
30
20
20
10
0 0
1985 1987 1989 1985 1987 1989

Inconnu Environnement Opérations Maintenance Matériel Logiciel

Page 11

© RJ Chevance

Analyse des défaillances(2)

 Analyse des causes de défaillances pour des systèmes
d’entreprise (Source : Standish Group 2000)
Digital TruClusters
IBM Parallel Sysplex

Autre cause Autre cause

5% 3%
Erreur de
Erreur de
Environnement l'opérateur
Environnement l'opérateur
6% 16%
6% 14%
Arrêt plannif ié Arrêt plannif ié
14% 16%
Erreur logiciel Erreur logiciel
17% 19%

Erreur
application Erreur application
19% Déf aillance 19%
Défaillance
matériel
matériel
23%
23%

Temps d'arrêts annuels d'exploitation

20
18
16
14
Heures

12 Temps d'arrêt système

10
8 Temps d'arrêt applicatifs
6
4
2
0
ya
er

)
UX

is
..
st

a
p.

ar
P-

al
lu

ys

ol

m
uC

rH

S
lS

Hi
Tr

er
te

le

q
t
s
q

us
al

pa

Page 12
lu
pa

ar

m
(c

(c
m

(P

Co
HP
Co

n
Su
M

© RJ Chevance
IB

Page 6
 Analyse des défaillances(3)

Disponibilité au niveau application et heures perdues
par an (Source : Gartner Group 2000)
Disponibilité niveau application (%) et heures perdues par an
100%
1 99,99%
99,9%
99,8%

99,6%

99% 99,2%

2,2 8,7 17,5 35,0 69,9

98%

OS/390 Parallel OS/390 AS/400 Clusters Unix Clusters NT Clusters

Sysplex
Source : Gartner Group 2000

Remarque : Ces chiffres ne sont pas cohérents avec ceux du Standish Group
Page 13

© RJ Chevance

Principes de conception

Concept d’état. Un système à haute disponibilité doit masquer
les défaillances auxquelles il est sujet à son environnement.
Deux possibilités :

Le système maintient en permanence plusieurs versions de
l’état courant

Le système maintient des états à partir desquels le traitement
peut être repris

Principes de conception

Modularité

Fail Fast : fonctionnement correct ou arrêt immédiat

Fail Safe : les conséquences des défaillances sont bénignes

Fail Silent : les défaillances sont du type «plantage»

Fail Stop : les défaillances se traduisent par un arrêt

Indépendance des modes de défaillance

Redondance et réparation

Élimination des points de défaillance uniques
Page 14

© RJ Chevance

Page 7
 Principes de conception(2)

Mise en œuvre des principes de conception

Concept Matériel Logiciel

Modularité • Classique • Classique
Fail Fast • Autovérification • Autovérification
• Comparaison • Programmation en N
versions
Indépendance des modes de défaillance • Mode de couplage entre les • Mode de couplage entre les
modules modules
Redondance et réparation • Modules de rechange • Redondance de certains
approche N+1 modules logiciel
• Échange de modules en • Remplacement du logiciel en
fonctionnement marche
Élimination des point de défaillance uniques • Redondance • Redondance

Page 15

© RJ Chevance

Solutions
Notes :

Les solutions proposées sont conçues
pour résister à une défaillance.

Pour la commodité de l ’exposé, on a
séparé les solutions en deux familles :
solutions au niveau du matériel et solutions
au niveau du logiciel. De fait, une solution
Page 16
est une combinaison des deux approches.
© RJ Chevance

Page 8
 Solutions au niveau du matériel

Page 17

© RJ Chevance

Stratus

«Pair and Spare» de Stratus

Illustration du concept
Données d'entrée

Proc Proc Proc Proc

Compare Compare

Primaire Secours
Données de sortie (backup)
Données de sortie

Sortie non validée

Principe de fonctionnement

Appariement (Pair) des organes actifs : le même processus est
exécuté en parallèle par deux processeurs au sein d’un même
organe

Doublement (Spare) des organes actifs : les deux organes
exécutent le même processus, l’un des deux est dit organe
primaire. Seules les sorties de l’organe primaire sont validées.
En cas de défaillance de l’organe primaire, l’organe de secours
prend le relais et ses sorties sont validées.
Page 18

Les différents organes peuvent être échangés sans interrompre
le fonctionnement du système.
© RJ Chevance

Page 9
 Stratus(2)

Architecture Continuum 4000 de Stratus
 Fondée sur processeurs HP PA 8000
 Deux systèmes d ’exploitation supportés :
 VOS Virtual Operating System (Stratus)
 HP-UX (Unix de HP adapté à PA)
 Prochaine génération à base d’IA-64

Valise 1 Cates PCI 7-10

Valise 0 Proc. Comp. Proc. Controlleur PCI

Proc. Comp. Proc. Interface
PCI #1 Cates PCI 11-13

Cartes PCI 4-6

Mémoire Interface
Mémoire PCI #0
Bus SCSI
Controlleur PCI

Alimentation Ventilateur Cartes PCI 0-3

Alimentation Ventilateur

Page 19

© RJ Chevance

Sun NETRAft
 NETRAft 1800 de Sun Microsystems
 Architecture du système
Bus PCI supportant la
P P connexion/déconnexion en marche
Pont PCI
P P Bus PCI supportant la CPUset
Horloge synchronisée

connexion/déconnexion en marche
Pont PCI (pouvant être changé pendant
Mémoire la marche du système)
A

Bus PCI supportant la

P P connexion/déconnexion en marche
Pont PCI
Bus PCI supportant la CPUset
P P connexion/déconnexion en marche (pouvant être changé pendant
Pont PCI
la marche du système)
Mémoire
B

 Principe de fonctionnement de type «Spare» (rechange)

Structure multiprocesseur (jusqu’à 4)

Processeurs fonctionnant de façon synchrone (horloge commune) mais sans
vérification à chaque pas

Les CPUsets exécutent le même ensemble de processus

Comparaison de l’état lorsqu’un processus fait une demande d ’entrée-sortie.
Si divergence, le système entame une phase de diagnostique pour
déterminer quel est le processeur défaillant
Page 20

Temps de recouvrement annoncé : 200 ms
© RJ Chevance

Page 10
 Sun NETRAft(2)

NETRAft 1800 de Sun Microsystems

Architecture du logiciel (Solaris)

Applications Applications

Applications standard
Gestion de la
Applications configuration

Solaris
(version standard) Système d'exploitation

Gestion des Pilotes de

exceptions périphériques Interface de machine
virtuelle sans défaillance

CPUset CPUset E/S E/S

Page 21

© RJ Chevance

IBM - Haute disponibilité

Haute disponibilité (hors clustering intra ou

inter-serveur par Sysplex) :

En l ’absence de données précises sur le z900, cet exposé
est fondé sur les caractéristiques de la génération
précédente G5

Concept de processeur de secours susceptible de venir
remplacer un processeur défaillant

Échange, en fonctionnement, des composants défaillants :

Matériel

Microcode

Logiciel?

Stratégie N+1 pour les modules d ’alimentation électrique
et les ventilateurs

Reprise au niveau instruction en cas de défaillance du
processeur (voir ci-après)
Page 22

© RJ Chevance

Page 11
 IBM - Haute disponibilité(2)
 Modèle d’exécution (S/390 G5 et G6) fondé sur :

La notion de point de reprise au niveau instruction

Le doublement, au sein même de l’unité de traitement, de la fonction
d’exécution avec comparaison pas à pas. En cas de divergence
possibilité de reprise :

Sur le même processeur (ré-essai)

Sur un processeur de secours (reprise)

Processeur Processeur
de secours
Unité Unité Unité Unité
de Cache de Reprise Reprise de Cache de
traitement traitement locale locale traitement traitement

Comparateur Comparateur

Registres Registres

Registres d ’état Registres d ’état

Rapport Ordre
d’erreur d’arrêt
Ordre de reprise
Module de
Page 23 surveillance

© RJ Chevance

Solutions au niveau du logiciel

Page 24

© RJ Chevance

Page 12
 Tandem
 NonStop Himalaya de Tandem
 Architecture du matériel
Mémoire Mémoire
Sous-système
processeur Principe de fonctionnement :
Proc. Comp. Proc. Proc. Comp. Proc.

Port Port Port Port • Architecture matérielle spécifique

ServerNet ServerNet ServerNet ServerNet
•Logique de type «pair»,
X Y X Y comparaison, cycle à cycle, des
sorties des processeurs;
R R R = Routeur ServerNet
• En cas de défaillance, pas de
fonction «spare», c’est un
Contrôleur E/S mécanisme de reprise logiciel
Contrôleur E/S Sous-système fondé sur la technique des points
R R d'entrées-sorties de reprise qui assure la poursuite
Contrôleur E/S
des activités (voir structure du
Contrôleur E/S logiciel sur la page suivante)
• Les points de reprise sont
R R déterminés par les bornes des
R R transactions (cette solution n’est
applicables qu’aux applications
transactionnelles)
Adaptateur Adaptateur • Les différents sous-ensembles
ServerNet ServerNet composant le matériel peuvent être
Sous-système échangés sans interrompre le
SCSI-2 SCSI-2 de stockage fonctionnement du système.

Page 25 SCSI-2 SCSI-2

© RJ Chevance

Tandem(2)
 NonStop Himalaya de Tandem
 Architecture du logiciel - Principe du processus de secours
(backup)

Réseau de communication

Processus A Processus A
(primaire) (secours)

Processus B Processus B
(secours) (primaire)

Système 1 Système 2

Information permettant la reprise

Page 26

© RJ Chevance

Page 13
 Solutions de type cluster (Unix et NT)
 Cluster IBM RS/6000 AIX HACMP (High Availability Cluster
MultiProcessing)
 Exemple de configuration

Charge de travail répartie

Bull Bull

Accès concurrents

DPX/20 DPX/20
Gestion du verrouillage
(Distributed Lock management)
Serveur A Serveur B
Oracle Parallel Server Disque Disque Oracle Parallel Server
1 2

Page 27

© RJ Chevance

Clusters - HACMP
 Architecture générale HACMP
Client Client Client

CLINFO CLINFO

CLINFO

Cluster Gestionnaire
du Cluster
Gestionnaire Agent SNMP
de verrous Cluster

 Architecture du gestionnaire du cluster src

dms
Gestionnaire du cluster
Configuration
du cluster gestionnaire
Contrôleur Gestionnaire
(odm) de verrous
du cluster d'événements
(CC) (EM)
agent SNMP cluster
Couche d'interface réseau

Scripts d'événements
NIM NIM NIM
Page 28
NIM : Network Interface Module
© RJ Chevance

Page 14
 Clusters - HACMP(2)
 Composants :
 CLINFO (Cluster Information Services) informe sur l ’état du
cluster (au moyen d ’une API)
 Agent SNMP rend l ’information fournie par le gestionnaire
du cluster accessible via SNMP
 Gestionnaire de verrous (Cluster Lock Manager) : service de
synchronisation distribué
 Gestionnaire du cluster : ensemble de services facilitant le
contrôle et la création des sous-systèmes

Contrôleur du cluster (Cluster Controller) reçoit l ’information
sur le cluster (via NIL et NIM) et est en relation avec src
(System Resource Controller). Il gère la base de données
représentant les objets du système (odm Object Data base
Manager)

Gestionnaire d’événements (Event Manager)

Couche d’interface réseau (Network Interface Layer - NIL)

Modules d’interface réseau (Network Interface Modules - NIM)
 Surveillance mutuelle par la technique du «Dead Man
Page 29 Switch» ou dms et des battements de cœur (Keep Alive)
© RJ Chevance

Clusters - HACMP(3)

Modes de fonctionnement
Systèmes "clients" Systèmes "clients" Systèmes "clients" Systèmes "clients"

Serveur A Serveur B Serveur B Serveur A Serveur B Serveur A Serveur B

(primaire) (secours) Appli1
Appli1
Applications Applications Applications Appli3 Appli2
critiques non critiques Appli2
Appli3
critiques

(2) (1) (2)

(1)
A) - Recouvrement simple B) - Recouvrement mutuel
(Hot Standby ou Simple Failover) (Mutual Takeover)

•Mutual Takeover ou Partionned Workload Configuration:

Hot Standby ou Simple Failover: l'application fonctionne sur l'un l'ensemble des systèmes participent à l'exécution des
des systèmes (primaire), un autre système est inactif (standby) ou applications. Chacun des systèmes opère sur des ressources
bien exécute des tâches indépendantes non-critiques (backup). En différentes (c’est-à-dire que les applications fonctionnant sur
cas de défaillance du système sur lequel l'application fonctionne, chacun des systèmes sont indépendantes et que les ensembles
le système de secours "prend" le relais en suspendant de fichiers qu’elles manipulent sont disjoints). En cas de
éventuellement l'exécution des tâches non-critiques. Lorsque le défaillance de l'un des systèmes, les applications qui
système primaire redevient opérationnel, il reprend le contrôle des s'exécutaient sur ce système sont reprises par l ’autre système.
ressources et l'exécution des applications critiques. La configuration présentée ici peut s'étendre à plusieurs noeuds.
Rotating Standby: le rôle du système primaire et du système de
secours ne sont pas figés, lorsque que le système primaire
redevient opérationnel, il se comporte comme système de Remarque Importante : Tous ces modes de fonctionnement
secours. n’apportent aucune garantie quant à l’état des fichiers suite à
une défaillance. Un système de fichiers journalisé (tel JFS
d ’AIX) permet de maintenir l’intégrité du conteneur mais pas
Page 30 celle du contenu. Cette intégrité peut être assurée par des
gestionnaires de données dans le cadre de transactions.
© RJ Chevance

Page 15
 Clusters - HACMP(4)

Modes de fonctionnement(2)
Systèmes "clients"

Serveur A Serveur B Serveur C

Application i Application j Application k

SGBD SGBD SGBD

Base de données
(partagée)

C) - Partage de charge
(Cluster MultiProcessing)

•Cluster MultiProcessing (CMP): les applications fonctionnant sur les différents systèmes accèdent à la même base de
données. En cas de défaillance de l'un des systèmes, ses applications sont reprises par les autres systèmes composant
le cluster.
• Les applications se synchronisent au moyen du Distributed Lock Manager.
• Outre la fonctionnalité de haute disponibilité, ce type de configuration autorise la croissance modulaire: chaque
système composant le cluster participe à l'exécution de la charge globale (redondance participative).
• Si les applications sont transactionnelles (propriétés ACID), la défaillance est équivalente à un abandon de transaction:
l'intégrité des données est assurée. En d'autres termes, il s'agit d'un fonctionnement en mode checkpoint avec
redondance participative.
• Ce mode implique un SGBD adapté à ce mode de fonctionnement, par exemple :
• DB2 Enterprise Edition;
Page 31 •Oracle Parallel Server.
© RJ Chevance

Cluster NT

Architecture Microsoft Cluster Server (MSCS)
Outils de Gestion du Cluster

Cluster API DLL

RPC (Appel de Procédure à Distance)

Service Cluster
Gestionnaire global
des mises à jour
Gestionnaire
Base de données
Traitement Gestionnaire
des évènements du nœud

Gestionnaire Autres nœuds

du recouvrement Gestionnaire
de communication
Gestionnaire
DLL de ressources
Ressource
application

Moniteurs de
ressources Interface de gestion des ressources

DLL DLL DLL Application non

Ressource Ressource Ressource adaptée au cluster
Page 32 physique logique application
Application
adaptée au cluster
© RJ Chevance

Page 16
 Cluster NT(2)
 Concepts :

Service Cluster : ensemble de logiciels implantés sur chacun des nœuds et gérant
les activités spécifiques du cluster

Ressource:

Entité gérée par le Service Cluster

Dite «en ligne» lorsqu’elle est supportée par nœud et fournit son service

Accédée au moyen de DLL

Groupe : collection de ressources (entité de gestion)
 Composants :

Gestionnaire du nœud (Node Manager) : gère l ’appartenance du nœud au cluster
et surveille l ’état des autres nœuds (technique des battements de cœur)

Gestionnaire de la base de données (Database Manager) : maintient la base de
données (répliquée) représentant l’état du cluster

Gestionnaire de ressource/gestionnaire de recouvrement : gère les ressources et
les groupes et lance les actions appropriées en cas de changement d’état

Traitement des événements : assure la connexion entre les composants du Service
Cluster et prend en charge les opérations communes

Gestionnaire de communications

Gestionnaire des mises à jour : prend en charge les fonctions de mise à jour des
composants du Service Cluster

Moniteurs de ressource : s ’assurent de l ’état de bon fonctionnement des
ressources (au moyen de «call backs»); implémentés sous forme de processus, ils
communiquent avec les services cluster au moyen de RPC
Page 33

Service de temps : fournit un temps homogène au sein du cluster
© RJ Chevance

Cluster NT(3)
 Principe de fonctionnement

En cas de défaillance d’une ressource, le gestionnaire de la ressource décide de :

de la redémarrer

de la mettre «hors ligne» et de la redémarrer sur un autre nœud (action prise en charge par
le gestionnaire de recouvrement)

En cas de défaillance d ’un nœud, la détermination du ou des nœuds prenant en
charge les groupes de ressources qui étaient supportés par le nœud défaillant est
négocié entre les «survivants»

Temporisation du redémarrage d ’une ressource pour éviter les défaillances
«oscillantes»

Processus d ’initialisation du cluster automatique avec découverte dynamique de la
configuration

Un nœud peut quitter un cluster (cluster exit)

Le temps de recouvrement est de l’ordre de la minute
 Visibilité des défaillances

Défaillance invisible pour les connexions sans état (ou stateless, ex. navigateurs) si
elle intervient entre deux requêtes (sinon c’est à l’application cliente -qui est
notifiée- d ’assurer la relance)

Pour des connexions avec état (statefull), c ’est aux applications de gérer la
reconnexion
 Intégrité des données : pas assurée en dehors du transactionnel (idem cluster
HACMP)
Page 34

© RJ Chevance

Page 17
 SafeTech

Technologie générique permettant de bâtir des solutions à haute
disponibilité sur des systèmes standard (NT ou Unix). Permet de
résister aux défaillances du matériel et du logiciel

Nécessite au moins deux systèmes interconnectés par un réseau
local

Ensemble de composants middleware installé sur la plate-forme et
fonctionnant sous le contrôle d ’un automate :
 Virtualisation de l ’adresse IP
 Système de fichiers redondant distribué
 Mécanisme de surveillance des systèmes
 Mécanisme de reconfiguration
 Mécanisme de partage de charge

Peut nécessiter une adaptation des applications pour pouvoir
bénéficier de la continuité de service

Deux modes de fonctionnement :
 primaire-secours (un seul système actif, l ’autre «suit»)
 partage de charge

Résultat d ’un coopération IRISA/Bull (voir http://www.evidian.com)
Page 35
Utilisé dans différents produits (ex pare-feu, serveur Web,…)
© RJ Chevance

SafeTech(2)

Architecture générale
Réponses des serveurs
Demandes des clients
Réseau de communication

Application Application
- Adresse IP virtuelle
- Réplication de fichiers
Composants Composants - Surveillance
SafeTech SafeTech - Reconfiguration
Automate Automate - Partage de charge

Système Système
d'exploitation d'exploitation
Système 1 Système 2

Fichiers répliqués
Dialogue entre automates de contrôle : échange d'information d'état, configuration,
battements de cœur (via le réseau local)

Page 36 Service de réplication de fichiers (via le réseau local)

© RJ Chevance

Page 18
 Recouvrement après catastrophe

Terme anglo-saxon : Disaster Recovery

Objectif : assurer la permanence du service (après interruption
éventuelle) en cas de catastrophe sur le site du système
d ’information (ex inondation, incendie, tremblement de terre,
émeute, ….)

Implique des sites géographiquement distants

Solutions coûteuses (ex 2 sites de même capacité de traitement
avec mise à jour synchronisée des données)

Quelques critères de choix d’une solution :
 Écart pouvant exister entre l ’état des données sur le site principal
et le site de secours
 Temps nécessaire à la reprise du traitement
 Coût de la solution

Quelques exemples pour diminuer le coût des solutions :
 Système de secours dimensionné comme le système primaire
mais utilisé pour d’autres tâches
Page 37
 Les deux sites jouent des rôles symétriques
© RJ Chevance
 Recours à un prestataire de service

Recouvrement après catastrophe(2)

Architecture générale d’une solution de recouvrement

Mécanisme
de surveillance
Classification des stratégies et des pratiques
de recouvrement (Gartner Group) :
Système primaire Système de secours • Niveau 0 : pas de recouvrement
• Niveau 1 : sauvegardes mais sans test des
sauvegardes
Copie de données • Niveau 2 : sauvegardes de la totalité du
stockage, à des moments
arbitrairement choisis, avec test
de leur contenu
• Niveau 3 : sauvegardes systématiques de la
Système 1 Système 2 totalité du stockage avec test de
leur contenu
• Niveau 4 : sauvegarde systématiques des
données relatives aux
applications critiques avec test
du contenu des sauvegardes
• Niveau 5 : mise à jour systématique et en
synchronisme avec le
déroulement des applications

Page 38

© RJ Chevance

Page 19
 Estimation de la disponibilité des systèmes

Page 39

© RJ Chevance

AMDEC/AEEL

AMDEC (Analyse des Modes de Défaillance, de leurs
Effets et de leur Criticité)
 Initialement utilisée pour le matériel, a été étendue au
logiciel (AEEL Analyse des Effets des Erreurs du Logiciel)
 Consiste à déterminer, pour chaque fonction ou
constituant d ’un système, ses modes de défaillance
possibles ainsi que les conséquences
 Quantification de la probabilité d’occurrence et de la
gravité des effets
 Évaluation de la criticité (synthèse sous la forme d’une
matrice)

Utilisable lors de la conception des systèmes
 permet de prévoir des couches défensives dans la
programmation
 pilotage des test de validation
 choix d ’une stratégie de maintenance
Page 40

© RJ Chevance

Page 20
 AMDEC/AEEL(2)

Structure d’un tableau AMDEC
FONCTION MODE DE CAUSE EFFET MOYEN DE DÉTECTION PROBABILITÉ GRAVITÉ CRITICITÉ ACTIONS
(COMPOSANT) DÉFAILLANCE CONSÉQUENCES (P) (G) (P × G)

Matrice de criticité (Source [MEI98])

Gravité
Prévention du risque Criticité

Très grave Zone

de risque
Grave intolérable
Réduction
Gênante du risque
Zone
Mineure de risque
tolérable
Minime
Probabilité d'occurrence

Très Faible Moyenne Fréquente Élevée

faible

La matrice peut être complétée par une troisième dimension qui représente la difficulté de détection.
Page 41

© RJ Chevance

Arbres de défaillance

Complète l’AMDEC qui ne traite pas les combinaisons des
défaillances. Permet de rechercher les causes d ’occurrence
d ’un événement redouté par la combinaison de clauses
logiques «et» et «ou». Exemple :
Fonctionnement
intempestif du
disjoncteur HT
Ouverture
intempestive OU
de la cellule ligne HT
Fonctionnement
intempestif de la
protection HT
Fonctionnement
intempestif du
disjoncteur arrivée
Ouverture
intempestive de la OU
cellule arrivée
Fonctionnement
Coupures dues intempestif de la
aux postes protection arrivée
OU Ouverture de la cellule
sources HT/MT OU
arrivée

Défaillance sur 1
des 9 autres lignes
Ouverture de MT
l'arrivée en secours ET Non fonctionnement du
d'un départ disjoncteur départ

Non élimination OU

Non fonctionnement de
Fonctionnement intempestif la protection départ
du disjoncteur départ
Ouverture intempestive
de la cellule ligne MT OU

Fonctionnement intempestif
de la protection
Page 42

© RJ Chevance

Page 21
 Estimation quantitative de la disponibilité

Les chaînes de Markov [SIE92] ou les réseaux de Petri stochastiques
permettent l ’estimation quantitative de la disponibilité des
systèmes. Dans le cas des chaînes de Markov, le graphe
état/transition est valué par des taux de défaillance λ et des taux de
réparation µ. La résolution du modèle donne la probabilité que le
système a de se retrouver dans différents états stationnaires.

1 λ2
λ1
λ

µ1 µ2
0 1 0 3
λ2
λ1

µ
µ2 2 µ1

Modèle de Markov Modèle de Markov

Système à 2 états Système doublé

Page 43

© RJ Chevance

Modèles de fiabilité du logiciel

Différents modèles de croissance de la fiabilité du logiciel ont été
proposés. Pratiquement, ces modèles servent à calibrer (à partir
d ’une loi de croissance) l’effort de test restant encore à effectuer
pour atteindre un objectif de fiabilité.
Intervalle de temps entre
défaillances dues au logiciel

Asymptote
(nombre total estimé
d'erreurs présentes
Objectif de dans le logiciel)
MTTF

Loi de croissance

MTTF
inital estimé
Temps de test
Temps de test supplémentaire estimé
Nombre d'erreurs
écoulé pour atteindre l'objectif nouvelles découvertes

Nombre d'erreurs Nombre d'erreurs supplémentaire

détectées à découvrir pour atteindre l'objectif

Page 44

© RJ Chevance

Page 22
 Comparaison des solutions

Comparaison (partielle) des propriétés des solutions
« Pair and Spare » Points de reprise Cluster Environnement d’exécution SafeTech
(matériel) (logiciel) (logiciel) (logiciel)
Tolérance aux
défaillances du Oui Oui Oui Oui
matériel
Tolérance aux Oui Oui
défaillances du Non Oui (Heisenbugs) et si absence de (Heisenbugs) et si absence de
logiciel de base (Heisenbugs) partage des données partage des données
Tolérance aux Oui Oui
défaillances du Non Oui (Heisenbugs) et si absence de (Heisenbugs) et si absence de
logiciel (Heisenbugs) partage des données partage des données
d’application
Programmation Oui en cas de partage et de mise à Oui en cas de partage et de mise à
spécifique des Non Oui jour des données jour des données
applications (logique transactionnelle)
Dégradation des
performances Non Oui Oui Oui
suite à
défaillance
Tolérance à la Oui Oui Oui Oui
réparation (nécessairement) (implicitement) (implicitement) (implicitement)

Coût/Performance

Temps de recouvrement
Performance O(x) signifie de l’ordre de x Coût
Système de base 1 Pas applicable 1
« Pair and Spare » <1 O(seconde) >>3
Système « Stand By » ~1 O(minute) ~2
Redondance participative
(deux systèmes se partageant la charge de <2 O(minute) ~>2
travail)

Page 45

© RJ Chevance

Perspectives

Augmentation du besoin de continuité de service

Augmentation de la fiabilité du matériel

Intégration des composants

Moyens de validation des composants

Intégration de la redondance et des moyens de masquage des
défaillances

Qualité de fabrication et de contrôle

Auto-surveillance des composants

Difficultés croissantes avec le logiciel

Volume sans cesse croissant du logiciel

Coût de la validation

Voies d ’exploration :

Conception de logiciel résistant aux défaillances

Conception du logiciel en vue du test

COTS

Concentration de l ’industrie et standardisation des solutions
(pour les systèmes d ’information car il reste des exigences non
couvertes par les technologies standard)
Page 46

Diminution de la part des solutions spécifiques de type matériel en
raison des progrès des solutions standard (clusters)
© RJ Chevance

Page 23
 Ouvrages et sites de référence
[CHE00] René J. Chevance «Serveurs multiprocesseurs, clusters et
architectures parallèles»
Eyrolles 2000
[GRA90] Jim Gray “A Census of Tandem System Availability Between 1985 and
1990 ”
IEEE Transaction on Reliability Vol 39., No 4., October 1990 pp409-418
[GRA91] Jim Gray, Daniel Siewiorek, “High Availability Computer Systems”
IEEE Computer, Vol. 24, No 9, September 1991, pp. 39-48.
[MEI98] Jean-Pierre Meinadier «Ingénierie et intégration des systèmes»
Hermès, 1998
[SIE92] Daniel P. Siewiorek, Robert S. Swarz, “Reliable Computer Systems
Design and evaluation”, 2nd Edition,
Digital Press, 1992.

Les sites des différents constructeurs de systèmes (parmi ceux qui ont été cités :
Compaq/Tandem, Bull/Evidian, IBM, Microsoft, Stratus et Sun)

Page 47

© RJ Chevance

Page 24