Théorie et Pratique du Système d’Information Huitième Chapitre: QoS et Haute-Disponibilité
Janvier-Mars 2009 Ecole Polytechnique
Yves Caseau
Plan du Cours – Architecture du Système d’Information
• Première partie:
Introduction à la Fiabilité
• Deuxième partie:
Fiabiliser le SI
• Troisième partie:
SLA: gestion contractuelle de la QoS
Fiabilité et Complexité
• La fiabilité des SI est souvent incriminée:
o Les SI sont des systèmes complexes
Nombreuses interactions (cf. 1 SI = 1 Airbus)
o Les conséquences sont très importantes
• Pourquoi ?
o Causes multiples (cf. Schmidt)
o Nature hybride :
beaucoup d’actions manuelles
Systèmes hétérogènes (assemblage)
• Qu’est-ce qui tombe en panne ?
o Marcus & Stern : pas de consensus !
o Les classiques:
System software : 27%
Hardware : 23%
Human error: 18%
Network failure: 17%
Natural disaster: 8%
Other: 7%
Première Partie: Formalisation
Fiabilité : Concepts Statistiques
• Le temps moyen d’occurrence d’une panne (MTTF = Mean Time to Fail) est le temps constaté entre le début et la fin d’une période de fonctionnement normal. La notion de moyenne ici s’effectue sur un ensemble d’équipements, pas sur la vie d’un équipement donné (cf. la notion de durée de vie).
• Le temps moyen de réparation (MTTR = Mean Time to Repair) est le temps qu’il faut pour détecter une défaillance, la réparer et remettre l’équipement en condition de
fonctionnement.
• Le temps moyen de défaillance (MTBF = Mean Time Between Failure) est la somme des deux.
• La disponibilité est le ratio (MTTF/MTBF).
temps MTBF = MTTF + MTTR
MTTR
OK
KO
MTTF
Disponibilité (%)
Première Partie: Formalisation
Disponibilité : Mesure logarithmiques (9s)
• La pratique veut que l’on mesure en « neufs »
o « trois neufs » représente 99,9%, soit une indisponibilité cumulée de 8h (un jour de travail) sur une année,
o « quatre neufs » représente 99,99%, soit une indisponibilité cumulée de 1h (52 minutes précisément) sur une année,
o « cinq neufs » représente 99,999%, soit une indisponibilité cumulée de 5 minutes sur une année.
• Ce chiffre s’interprète selon les exigences de service:
o 24 x 7, 24 x 6, 14 x 5, …
• La notion de disponibilité s’applique pour des « événements statistiques »:
o Pannes: HW, réseau, erreur de paramétrages, facilités, …
o Pas des « accidents logiciels » ou des « désastres » Première Partie: Formalisation
Durée de vie et MTBF
• La fiabilité évolue au cours du temps en fonction du cycle de vie:
• Attention aux phases de mise en service
• Attention à la gestion des équipements en fin de vie
o Cf. chapitre 5 sur les « coûts du socle »
Fréquence des incidents
âge usure Durée de vie
jeunesse
Période stable de définition du MTBF
Première Partie: Formalisation
Fiabilité du matériel
• Il existe une grande variabilité selon la qualité des composants et surtout selon l’architecture matérielle
o Redondance à tous les niveaux (ex: alimentation)
• Les fiabilités des matériels sont mesurées et publiées par les constructeurs.
o Attention les valeurs en laboratoire sont toujours meilleures que la réalité
• Les valeurs observées de disponibilité :
o De 99.9% à 99.99%
The 2006 survey found that both Linux and Windows Server 2003 (nine hours per server per year) were relatively crash-prone compared to Unix, but that the Linux systems surveyed have now closed the gap slightly.
Unix systems, which represented about 10 percent of the installed base covered by the survey, still achieved the highest reliability figures. IBM's AIX came
highest, with enterprises reporting an average of 36 minutes of downtime per server over a 12-month period. HP-UX version 11.1 recorded 1.1 hours of downtime, while Sun Solaris users reported 1.4 hours per server, per year.
ZDNET : Yankee Group Survey
Première Partie: Formalisation
Fiabilité du logiciel
• Cycle
o Fault/defect > error > failure
o Soft or hard failure: pb de la détection
• Fiabilité des composants
o Software reliability metrics: taille et complexité
o Liée à la qualité du processus de fabrication
• Fiabilité des assemblages
o Versions
o Compatibilité
• Axiome : il reste toujours des défauts
o CJ: 0.4 défaut par point de fonction
(commercial SW, small)
o 1MLOC: 10-20 kPF : 4-8K
source: http://www.sei.cmu.edu
Première Partie: Formalisation
Anatomie d’une crise
• Causes multiples vs. confiance dans les plans de protections
• Plus le temps de détection est long, plus les dégâts sont importants
• La crise provoque un état de fonctionnement non nominal qui peut provoquer d’autres fautes : effet de cascade
• Les temps de migration de données sont sous-estimés
• Cf. Ch. Perrow « Normal Accidents »
Cause Alerte :
Détection Diagnostic
Effet :
Dégradation Analyse Action Réparation Restauration
Si action insuffisante → boucle
Si durée prévisionnelle est trop longue → Activation du Plan de secours Durée de restauration des données
Dernière sauvegarde
Perte éventuelle de données
Première Partie: Formalisation
Risque et Incertitude
Cf. Bernstein’s « a History of Risk »
• Risque: des évènements pour lesquels il existe un historique et pour lesquels la gestion statistique est possible,
entrainant des pertes linéaires en fonction de l’indisponibilité
• Incertitude: les évènements graves sans statistiques, entrainant des pertes non linéaires
Deux gestions contractuelles avec la maîtrise d’ouvrage:
• Les SLA (cf. plus loin) pour la gestion des incidents
• Le plan de secours, défini en terme de:
o RTO: Recovery Time Objective (DMIA)
o RPO: Recovery Point Objective (PDMA)
Durée indisponibilité Pertes
(€) Probabilité
(a)
Incidents : Traitement
quantitatif Crises :
Traitement qualitatif
indirectes productivité Directes (CA)
Étude de scénarios
Première Partie: Formalisation
AMDEC
• Issu de l’armée américaine: « Procédures pour l'Analyse des Modes de Défaillance, de leurs Effets leurs Criticités » (1949)
o Une AMDEC est défini comme "un procédé systématique pour identifier les modes potentiels et traiter les défaillances avant qu'elles ne surviennent, avec l'intention de les éliminer ou de minimiser les risques associés.
• Pour réaliser une AMDEC, on utilise un tableau qui comporte les colonnes suivantes :
o identification du composant ou du sous-ensemble,
o identification de la ou des défaillances pouvant affecter le composant ou le sous-ensemble,
o recherche des conséquences de cette (ces) défaillance(s) sur le système,
o Probabilité/facilité de détection
o cotations de la fréquence, gravité et probabilité de non-détection de la
défaillance,
o évaluation de la criticité (en général on retient le produit fréquence × gravité).
Première Partie: Formalisation
Plan de Secours (Disaster Recovery Plan)
• PCA : plan de continuité d’activité
o Orienté processus métier
o Avec l’assistance et l’implication de la maîtrise d’ouvrage
• Composants:
o Scénarios (et tests associés)
o Ressources de calcul
o Données (back-up & restore)
o Procédures (à suivre, rigoureusement définies)
• Double arbitrage économique:
o Périmètre des scénarios à couvrir
Utilisation des AMDEC pour prioriser
o Prix de la solution de continuité
Shared System, Cold Standby, Hot Standby
cf. section suivante (parallèle avec haute-disponibilité) … mais sur des lieux différents
Première Partie: Formalisation
Deuxième partie
• Introduction à la Fiabilité
• Fiabiliser le SI
• SLA: Gérer la qualité de service
Fiabilisation matérielle
• Meilleure disponibilité:
o Augmenter le MTBF
o Réduire le MTTR (partie suivante)
• Fiabiliser (cf. livre de Klaus Schmidt)
o Robustesse
o Redondance = repetition + (replication + fault handling)
• Trois pistes:
o Matériel fiable
o Matériel redondant (clusters)
o Architecture redondante Deuxième Partie: Fiabiliser le SI
Matériel Fiable
• Cf. point précédent : les serveurs
« haut-de-gamme » sont plus fiables (sauf exceptions)
o HW dédié « fault-tolerant »
o (ex: Status): 99.999%
• Stockage
o Technologies RAID (1 à 5)
• Importance du contrat de maintenance
o Détermine le temps d’intervention (fonction du coût)
o Suivre les statistiques de disponibilité
et d’intervention – éviter les « mauvaises séries »
• Importance des condition d’hébergement
o Redondance de l’alimentation électrique
o Redondance de la réfrigération Deuxième Partie: Fiabiliser le SI
Clusters
• Redondance binaire
o Actif/passif
o Actif/actif
• Avantages
o Solution classique éprouvée
o Applicable avec des configurations simples
o Solution DBMS
• Inconvénients
o Détection : maillon faible
o Failover: 90/95% de succès est un bon chiffre (Schmidt)
o Actif/actif: attention à la surcharge
o Maintenir deux copies exactes Deuxième Partie: Fiabiliser le SI
Architectures redondantes
• Redondance N/N+1
o Ou N/N+2, etc
o Le répartiteur doit être HA .
• Très judicieux pour les traitements sans mémoire/état
• Adapté pour une architecture N- tiers
o Il faut également une approche HA pour les BD
• Peut-être combiné avec une stratégie de virtualisation
o Découper une machine en machines logiques
o HA: utiliser une « ferme »
o DRC: plusieurs sites Deuxième Partie: Fiabiliser le SI
Fiabilisation logicielle
« Big Picture »: 3 approches
• Test
o Éliminer le plus de défauts possible
• Fault-tolerance et construction rigoureuse des applications
o Résister aux défauts
o Détecter les problèmes
• Redondance logicielle
o Cf. approche matérielle
Principe KISS: Keep It Simple, Stupid
• Cf. chapitre 4 – la complexité est l’ennemi de la fiabilité
• Nombre des interactions possibles
• Capacité à documenter et transmettre ce qui est sophistiqué Deuxième Partie: Fiabiliser le SI
Tests
Trois difficultés:
• Couverture
o Bonne pratique: mesurer des taux de couverture statiques
• Temps (surtout en mode projet – can you see why ? )
o Automatiser !
o Penser aux tests le plus tôt possible
• Coût
o Optimisation économique – pas facile à trouver en pratique
: détection (# anos) : détection (fréquence)
fin du test
# total anomalies
seuil rentabilité marginale
Stock résiduel
Deuxième Partie: Fiabiliser le SI
« Fault Tolerance »
La qualité des applications joue un rôle essentiel (La Palisse)
• Résister aux erreurs:
o Fault -> error:
respecter les normes de qualité de code
Utiliser les outils de qualimétrie (ex: Purify)
Assertions, contrats, etc.
o Error –> failure: gestion des erreurs
• Détecter les erreurs / soft failures
o Gestion des performances
o Auto-diagnostic
• Permettre une relance plus rapide
o Recovery point (back-up)
o Démarrage rapide Deuxième Partie: Fiabiliser le SI
Redondance Logicielle
• Redondance + vote : 3 versions
o Nécessite 3 implémentations différentes
o Utilisé dans les secteurs militaires et aéronautiques
o Coût très important (pas seulement fois 3 )
o Exige une spécification impeccable (facteur de coût) pour que les trois implémentations coïncident.
• Redondance dans l’exécution des processus métiers:
o Prévoir et traiter les cas d’erreur
o Mécanismes de rejeu et de retraitement des données (solutions dégradées)
• Parallélisation massive (GRID)
o Ne résous pas les problèmes de design et les erreurs de programmation
o Se prête mieux à la programmation hybride/redondante
Méthodes par approximation successives
Combinaison d’agents
Réparation « à chaud »
2 versions ne suffisent pas : comment savoir laquelle se « trompe » ?
Deuxième Partie: Fiabiliser le SI
Détection Rapide et mise en œuvre des palliatifs
• S’appuie sur des outils logiciels standards
o Cf. Marcus & Stern (Chap. 16) : se méfier des solutions ad hoc
o Surveiller le réseau !
• Gestion des performances, des files d’attentes, …
o Cf. chapitre suivant
o Suivre les indicateurs métiers (sous forme d’alertes)
La vision métier est souvent plus fine que la vision technique ex: défaut de paramétrage de facturation
• Qualité des opérations – cf. plus loin
• Tester régulièrement les mécanismes de partage – automatique et manuels (procédures)
• Garder de la flexibilité
o L’expérience montre qu’on se tire souvent d’une crise avec des matériels supplémentaires (pas forcément ceux qu’on croit)t
Deuxième Partie: Fiabiliser le SI
Récupération Rapide
• Schéma tiré de Marcus & Stern
• La gestion des données est souvent un facteur aggravant dans une crise
o « Back-up » corrompus (surtout les version incrémentales)
o Temps de chargement plus long que prévu
o C’est là qu’on réalise que le planning des back-up ne respecte pas le RPO parce qu’il a été « optimisé »
Secs Mins Hours Days
Clusters
Manual Migration
Tape Restore
downtime Data Loss
Mins Secs Hours
Days
Tape
Back-up Periodic Replication
Async Replication
Sync Replication or Mirroring
Deuxième Partie: Fiabiliser le SI
Troisième Partie
• Introduction à la Fiabilité
• Fiabiliser le SI
• SLA: Gérer la qualité de service
SLA: Service Level Agreement
• Un terme et une pratique qui vient des télécom
o Détermine la qualité de service qui doit être fournie au moyen d’indicateurs mesurables
o De disponibilité
o De performance
• Le SLA est un contrat qui lie les deux parties
o La DSI s’engage à tenir ses engagements
Dans le cas d’une externalisation, il y a des pénalités associées
o Le client accepte le compromis et attends la renégotiation pour relever ses exigences:
SLR: Service Level Requested
• Le SLA est un outil de pilotage
• Le SLA est le résultat d’une négociation (souhaitable)
o Force la DSI à expliquer ses contraintes, ses capacités, ses coûts
o Force la MOA à expliquer ses enjeux métiers
Gestion économique du SLA
• La perte produite par les
incidents n’est pas seulement un perte d’usage, mais
également une perte d’efficacité qui doit être
mesurée, ce qui permet de piloter l’effort récurrent de
fiabilisation 98 % 100%
Coûts (€)
disponibilité Coût de non-efficacité
Coût de fiabilisation Coût total
amélioration
Durée totale indisponibilité Pertes
Coûts (€)
SLA théorique
Coûts Pertes
• Le SLA optimal correspond à un équilibre entre les pertes et les surcoûts d’exploitation
• Le SLA réel tient compte de
o La capacité à faire,
technique et budgétaire
o Un arbitrage de risque
(dépenses sures vs. Pertes possibles)
incidents
Importance des procédures
• Axiome (Schmidt):
« No tool and no automation can save you from bad operations – bad operations will make any good design fail. It is the biggest threat in high availability »
• S’appuyer sur des procédures
o Leçon tirée du monde industriel (systèmes critiques)
Nucléaire, chimie, transport aérien, etc.
o Documentée, appliquées, vérifiées
• S’appuyer sur un référentiel
o ITIL: standard de fait, produit au Royaume-Uni dans les années 80
Office public britannique du commerce (OGC)
o Ensemble de bonnes pratiques
o Référentiel de processus
Service Support
Service Delivery
o Fournit un vocabulaire commun
Processus Internes (ITIL)
Importance de la compétence
• Professionnalisme
o La combinaison des niveaux d’exigence/excellence modernes et des objectifs de réduction de coût exige la professionnalisation des opérations de production
o Internalisé ou externalisé / formation ou concentration
Pourquoi externaliser : parce qu’on fait mieux si on fait souvent et sur des gros volumes
Internaliser: pour développer une compétence propre
• Compétences sur le SI
o Essentiel pour le bon diagnostic préventif
o Fondamental en cas de crise (expérience Bytel)
c’est ce qui permet de trouver les « contournements »
• Intégrité
o Savoir résister aux changements trop rapides
o Appliquer les règles de l’art
o Effectuer les tests prévus
Cf. les livres sur les histoires des crises … (ex. Perrow, Colwell)
Amélioration continue de la QoS
• La qualité de service est le domaine idéal pour une approche DMAIC:
o Sujet difficile, il est irréaliste de tout réussir du premier coup
o Les métriques de succès liées au SLA existent
o Les échecs sont une source constante d’enrichissement
Si on les prend comme tel (culturellement)
• Il faut capitaliser les connaissances !
o Exigence sur les documentations
o Tracer les incidents, collecter les métriques, etc.
• Exemple: comité fiabilisation (Bytel, 2004-2005)
o Transverse: tous les métiers de la DSI.
La QoS n’est pas simplement l’affaire de la production
o Prioriser et concentrer son énergie.
o Aller au fond des choses (ce qui peut prendre du temps)
o S’appuyer sur des mesures et fixer des critères de sortie
Importance du monitoring
• La supervision des processus a un double objectif
o Vérifier les SLA (Service Level Agreements) pour intervenir sur les incidents
o Suivre le fonctionnement de façon préventive
• Elle s’appuie sur deux principes
o Génération et remontée d’alarmes (cf. détection)
o Corrélation (remonter les niveaux d’abstraction)
Processus métier
Processus
technique Système
technique Système fonctionnel
Système Applicatif SL Monitoring
Incident Monitoring
Diagnostic requêtes
Alertes + stats +
SLA SLA
incident erreur BAM
Pilotage des processus
• Urbanisation => IT orientée-processus
=> meilleur pilotage
• BPM/BAR ->
des outils de plus en plus pertinents
MAIS
• Double cycle de maturation
• Vraie complexité
Système Application Processus
Maturité métier
Maturité technique
Incident Erreur
SLA
Exploitation:
Automatisée 7/7 24/24
MOE -> MOA:
Suivi
Tableau de bord
MOA:
Analyse SI bleus
Première étape:
Appropriation des processus
II.2 : Processus - Exploitation
Production organique
• S’inscrit dans la vision « Autonomic computing »
• Gestion des incidents différente (à chaud, ..)
• Fiabilisation différente (modèle organique)
ST1 ST2 ST3
ST1
secours ST3
secours Bascule
auto
Monitoring/ Réaction par système
Bascule manuelle
Monitoring + Réaction au niveau du processus
ST1 ST2 ST3
réflexe ST4 contourneme
nt
Vision
« biologique » Vision
« mécanique »
Conclusion (Marcus & Stern)
• Il faut simplifier l’architecture et la conception du système d’information car chaque point complexe est une source de problèmes (le principe KISS)
• Il faut choisir des équipements dans une phase mature de leur vie commerciale, qui ont déjà été déployés et utilisés avec succès par d’autres entreprises.
• Il faut tout tester, et de façon régulière. C’est la recommandation qui semble la plus triviale, c’est pourtant celle qui arrive en premier dans la bouche de tous les
spécialistes.
• Il faut construire des systèmes « scalables », c’est-à-dire penser à la croissance dès le début, même si les spécifications ne font pas mention de ce besoin. C’est
l’expérience qui parle : une très grande partie des problèmes en production vient de systèmes qui ont atteint les limites de leur « zone de confort ».
• Il ne faut pas faire des mauvaises économies (« don’t be cheap »). Cela s’applique bien sûr au matériel et au logiciel, mais aussi aux ressources humaines, en terme de nombre et de niveaux de compétence.
• Il faut s’appuyer sur des contrats de services, qui sont eux-mêmes rendus explicites et propres au pilotage quantitatif par la notion de niveaux de services. Nous
aborderons ce point dans la section suivante.
• Il faut automatiser le plus possible, pour éliminer le facteur humain qui est source d’erreur, et pour pouvoir industrialiser la gestion des configurations.
• Il faut surveiller la performance de façon continue, les ralentissements étant souvent les symptômes annonciateurs des incidents.
