Upload
yves-caseau
View
955
Download
0
Embed Size (px)
DESCRIPTION
Cours sur le système d'information en 9 chapitres
Citation preview
Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) 1/28
Théorie et Pratique du Système Théorie et Pratique du Système d’Informationd’InformationHuitième Chapitre: QoS et Haute-Huitième Chapitre: QoS et Haute-DisponibilitéDisponibilité
Janvier-Mars 2012Ecole Polytechnique
Yves Caseau
Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) 2/28
Plan du Cours – Architecture du Système Plan du Cours – Architecture du Système d’Informationd’Information
Première partie:Introduction à la Fiabilité
Deuxième partie: Fiabiliser le SI
Troisième partie:SLA: gestion contractuelle de la QoS
Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) 3/28
Fiabilité et ComplexitéFiabilité et Complexité
La fiabilité des SI est souvent incriminée: Les SI sont des systèmes complexes
Nombreuses interactions (cf. 1 SI = 1 Airbus) Les conséquences sont très importantes
Pourquoi ? Causes multiples (cf. Schmidt) Nature hybride :
beaucoup d’actions manuelles Systèmes hétérogènes (assemblage)
Qu’est-ce qui tombe en panne ? Marcus & Stern : pas de consensus ! Les classiques:
System software : 27% Hardware : 23% Human error: 18% Network failure: 17% Natural disaster: 8% Other: 7%
II.1 : Processus - Principes
Pre
miè
re P
art
ie:
Form
alisati
on
Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) 4/28
Fiabilité : Concepts StatistiquesFiabilité : 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é (%)
La pratique veut que l’on mesure la disponibilité en « neufs »
•« trois neufs » représente 99,9%, soit une indisponibilité cumulée de 8h (un jour de travail) sur une année,•« quatre neufs » représente 99,99%, soit une indisponibilité cumulée de 1h (52 minutes précisément) sur une année,•« 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:
•24 x 7, 24 x 6, 14 x 5, …
Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) 5/28
Durée de vie et MTBFDuré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
Cf. chapitre 5 sur les « coûts du socle » La notion de disponibilité s’applique pour des « événements statistiques »:
Pannes: HW, réseau, erreur de paramétrages, facilités, … Pas des « accidents logiciels » ou des « désastres »
Fréquencedesincidents
âge
usure
Durée de vie
jeunesse
Période stable de définition du MTBF
Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) 6/28
Fiabilité du matérielFiabilité du matériel
Il existe une grande variabilité selon la qualité des composants et surtout selon l’architecture matérielle
Redondance à tous les niveaux (ex: alimentation) Les fiabilités des matériels sont mesurées et publiées par les
constructeurs. Attention les valeurs en laboratoire sont toujours meilleures que la
réalité Les valeurs observées de disponibilité :
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
Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) 7/28
Fiabilité du logicielFiabilité du logiciel
Cycle Fault/defect > error > failure Soft or hard failure: pb de la détection
Fiabilité des composants Software reliability metrics: taille et complexité Liée à la qualité du processus
de fabrication Fiabilité des assemblages
Versions Compatibilité
Axiome : il reste toujours des défauts
CJ: 0.4 défaut par point de fonction (commercial SW, small)
1MLOC: 10-20 kPF : 4-8Ksource: http://www.sei.cmu.edu
Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) 8/28
Anatomie d’une criseAnatomie 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 »
CauseAlerte :
DétectionDiagnosticEffet :
DégradationAnalyse 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èresauvegarde
Perte éventuelle de données
Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) 9/28
Risque et IncertitudeRisque 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: RTO: Recovery Time Objective (DMIA) RPO: Recovery Point Objective (PDMA)
Durée indisponibilité
Pertes(€)Probabilité
(a)
Incidents :Traitementquantitatif Crises :
Traitement qualitatif
indirectes
productivité
Directes (CA)
Analyse probabiliste
Étude de scénarios
Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) 10/28
AMDECAMDEC
Issu de l’armée américaine: « Procédures pour l'Analyse des Modes de Défaillance, de leurs Effets leurs Criticités » (1949)
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 :
identification du composant ou du sous-ensemble, identification de la ou des défaillances pouvant affecter le composant ou le
sous-ensemble, recherche des conséquences de cette (ces) défaillance(s) sur le système, Probabilité/facilité de
détection cotations de la fréquence,
gravité et probabilité de non-détection de la défaillance,
évaluation de la criticité (en général on retient le produit fréquence × gravité).
Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) 11/28
Plan de Secours (Plan de Secours (Disaster Recovery PlanDisaster Recovery Plan))
PCA : plan de continuité d’activité Orienté processus métier Avec l’assistance et l’implication de la maîtrise d’ouvrage
Composants: Scénarios (et tests associés) Ressources de calcul Données (back-up & restore) Procédures (à suivre, rigoureusement définies)
Double arbitrage économique: Périmètre des scénarios à couvrir
Utilisation des AMDEC pour prioriser 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
Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) 12/28
Deuxième partieDeuxième partie
Introduction à la Fiabilité Fiabiliser le SISLA: Gérer la qualité de service
Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) 13/28
Fiabilisation matérielleFiabilisation matérielle
Meilleure disponibilité: Augmenter le MTBF Réduire le MTTR (partie suivante)
Fiabiliser (cf. livre de Klaus Schmidt) Robustesse Redondance = repetition + (replication + fault handling)
Trois pistes: Matériel fiable Matériel redondant (clusters) Architecture redondante
Deu
xiè
me P
art
ie:
Fia
bilis
er
le S
I
Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) 14/28
Matériel FiableMatériel Fiable
Cf. point précédent : les serveurs « haut-de-gamme » sont plus fiables (sauf exceptions)
HW dédié « fault-tolerant » (ex: Status): 99.999%
Stockage Technologies RAID (1 à 5)
Importance du contrat de maintenance Détermine le temps d’intervention
(fonction du coût) Suivre les statistiques de disponibilité
et d’intervention – éviter les « mauvaises séries » Importance des condition d’hébergement
Redondance de l’alimentation électrique Redondance de la réfrigération
Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) 15/28
ClustersClusters
Redondance binaire Actif/passif Actif/actif
Avantages Solution classique
éprouvée Applicable avec des
configurations simples Solution DBMS
Inconvénients Détection : maillon faible Failover: 90/95% de succès
est un bon chiffre (Schmidt) Actif/actif: attention à la surcharge Maintenir deux copies exactes
Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) 16/28
Architectures redondantesArchitectures redondantes
Redondance N/N+1 Ou N/N+2, etc Le répartiteur doit être HA .
Très judicieux pour les traitements sans mémoire/état
Adapté pour une architecture N-tiers
Il faut également une approche HA pour les BD
Peut-être combiné avec une stratégie de virtualisation
Découper une machine en machines logiques
HA: utiliser une « ferme » DRC: plusieurs sites
Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) 17/28
Fiabilisation logicielleFiabilisation logicielle
« Big Picture »: 3 approches Test
Éliminer le plus de défauts possible Fault-tolerance et construction rigoureuse des applications
Résister aux défauts Détecter les problèmes
Redondance logicielle 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é
Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) 18/28
TestsTestsTrois difficultés: Couverture
Bonne pratique: mesurer des taux de couverture statiques Temps (surtout en mode projet – can you see why ? )
Automatiser ! Penser aux tests le plus tôt possible
Coût Optimisation économique – pas facile à trouver en pratique
temps
: détection (# anos): détection (fréquence)
fin du test
# totalanomalies
seuilrentabilitémarginale
Stock résiduel
Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) 19/28
«« Fault ToleranceFault Tolerance » »
La qualité des applications joue un rôle essentiel (La Palisse) Résister aux erreurs:
Fault -> error: respecter les normes de qualité de code Utiliser les outils de qualimétrie (ex: Purify) Assertions, contrats, etc.
Error –> failure: gestion des erreurs Détecter les erreurs / soft failures
Gestion des performances Auto-diagnostic
Permettre une relance plus rapide Recovery point (back-up) Démarrage rapide
Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) 20/28
Redondance LogicielleRedondance Logicielle
Redondance + vote : 3 versions Nécessite 3 implémentations différentes Utilisé dans les secteurs militaires et aéronautiques Coût très important (pas seulement fois 3 ) 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:
Prévoir et traiter les cas d’erreur Mécanismes de rejeu et de retraitement des données (solutions
dégradées) Parallélisation massive (GRID)
Ne résout pas les problèmes de design et les erreurs de programmation
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 » ?
Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) 21/28
Détection Rapide et mise en œuvre des palliatifsDétection Rapide et mise en œuvre des palliatifs
S’appuie sur des outils logiciels standards Cf. Marcus & Stern (Chap. 16) : se méfier des solutions ad hoc Surveiller le réseau !
Gestion des performances, des files d’attentes, … Cf. chapitre suivant Suivre les indicateurs métiers (sous forme d’alertes)
La vision métier est souvent plus fine que la vision techniqueex: 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é
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
Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) 22/28
Récupération RapideRécupération Rapide
Schéma tiré de Marcus & Stern
La gestion des données est souvent un facteur aggravant dans une crise
« Back-up » corrompus (surtout les version incrémentales) Temps de chargement plus long que prévu 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
ClustersManual Migration
Tape Restore
downtimeData Loss
SecsMinsHoursDays
Tape Back-upPeriodic
Replication
Async Replication
Sync Replicationor Mirroring
Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) 23/28
Troisième PartieTroisième Partie
Introduction à la Fiabilité Fiabiliser le SISLA: Gérer la qualité de service
Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) 24/28
SLA: SLA: Service Level AgreementService Level Agreement
Un terme et une pratique qui vient des télécom Détermine la qualité de service qui doit être fournie au moyen
d’indicateurs mesurables De disponibilité De performance
Le SLA est un contrat qui lie les deux parties La DSI s’engage à tenir ses engagements
Dans le cas d’une externalisation, il y a des pénalités associées 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)
Force la DSI à expliquer ses contraintes, ses capacités, ses coûts Force la MOA à expliquer ses enjeux métiers
Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) 25/28
Gestion économique du SLAGestion é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
100%98 %
Coûts (€)
disponibilité
Coût de non-efficacité
Coût de fiabilisation
Coût total
amélioration
Durée totale indisponibilité
PertesCoû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 La capacité à faire,
technique et budgétaire Un arbitrage de risque
(dépenses sures vs. Pertes possibles)
incidents
Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) 26/28
Importance des procéduresImportance 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 Leçon tirée du monde industriel (systèmes critiques)
Nucléaire, chimie, transport aérien, etc. Documentée, appliquées, vérifiées
S’appuyer sur un référentiel ITIL: standard de fait, produit au Royaume-Uni dans les années 80
Office public britannique du commerce (OGC) Ensemble de bonnes pratiques Référentiel de processus
Service Support Service Delivery
Fournit un vocabulaire commun
Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) 27/28
Importance de la compétenceImportance de la compétence
Professionnalisme 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
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 Essentiel pour le bon diagnostic préventif Fondamental en cas de crise (expérience Bytel)
c’est ce qui permet de trouver les « contournements » Intégrité
Savoir résister aux changements trop rapides Appliquer les règles de l’art Effectuer les tests prévus
Cf. les livres sur les histoires des crises … (ex. Perrow, Colwell)
Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) 28/28
Importance du monitoringImportance du monitoring
La supervision des processus a un double objectif Vérifier les SLA (Service Level Agreements) pour intervenir sur les
incidents Suivre le fonctionnement de façon préventive
Elle s’appuie sur deux principes Génération et remontée d’alarmes (cf. détection) 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
Diagnosticrequêtes
Alertes +
stats +
SLA SLA
incident
erreurBAM
II.2 : Processus - Exploitation