This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
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é
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:
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.
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
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é).
É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é
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 » ?
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
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
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