cours chapitre8 2012

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


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


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


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, …


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


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


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


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


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


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é).


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


Deuxième partieDeuxième partie

Introduction à la Fiabilité Fiabiliser le SISLA: Gérer la qualité de service


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


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


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


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


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é


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


«« 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


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 » ?


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


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


Troisième PartieTroisième Partie

Introduction à la Fiabilité Fiabiliser le SISLA: Gérer la qualité de service


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


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


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


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)


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

cours chapitre8 2012

Education