Cours chapitre8 2012

1,505 views
1,304 views

Published on

Cours sur le système d'information en 9 chapitres

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,505
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
94
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • une chaussure a une durée de vie de quelques années et un temps moyen de panne de plusieurs milliers d’années : il n’y a qu’une chance sur mille de devoir changer sa chaussure avant d’avoir atteint la phase d’usure (le taux de panne prend son sens sur un échantillon d’un million de chaussure).
  • Dans la pratique, les serveurs informatiques produisent des disponibilités qui vont de 99.9% pour des matériels bas de gamme à 99.99% pour des serveurs haut de gamme. La corrélation avec le prix est une approximation, il y a des matériels chers et fragiles, ainsi que des serveurs Intel Windows ou LINUX (serveurs d’ « entrée de gamme ») avec de très bonnes disponibilités. Il y a presque un ordre de grandeur de différence entre ces chiffres qui reflètent « la vraie vie » et ce qui est observé en laboratoire et qui est publié dans les brochures. N’étant pas un spécialiste du hardware, je ne peux que me hasarder à deux conjectures pour expliquer cette différence. Premièrement la charge et les conditions de charge (température, mode de fonctionnement, etc.) sont plus régulières en laboratoire que dans la vraie vie. Deuxièmement le « MTTR pratique » est plus long que le MTTR de laboratoire qui est proche du MTTR théorique (dans la vraie vie, il y a les week-ends, les mauvais diagnostics, les pièces en rupture de stock, les encombrements, etc.).
    http://www.zdnet.com.au/news/hardware/soa/Windows-Server-reliability-crashes-in-2007/0,130061702,339288227,00.htm
  • http://satc.gsfc.nasa.gov/support/ISSRE_NOV98/software_metrics_and_reliability.html
    http://www.softrel.com/Current%20defect%20density%20statistics.pdf
    http://www.sans.org/top25errors/print.pdf
    Il s’agit des 25 erreurs de programmation les plus graves/classiques/ennuyeuses lorsqu’on développe.
     
  • La durée maximale d'interruption admissible, en anglais Recovery Time Objective (RTO) constitue le temps maximal acceptable durant lequel une ressource (généralement informatique) peut ne pas être fonctionnelle après une interruption majeure de service.
    Le RTO est considéré en conjonction avec le Recovery Point Objective (RPO) qui quantifie la capacité de reprise sur sauvegarde de la ressource. L'ensemble permet de déterminer le temps total d'interruption d'une ressource après un incident majeur.
    Ce délai d'interruption de service se décompose en :
    Délai de détection de l'incident
    Délai de décision du passage en secours (s'il n'est pas automatique)
    Délai de mise en oeuvre des procédures de secours (aiguillage réseau, restauration des données...)
    Délai de controle + relance de l'application
    La somme de ces délais doit en théorie être inférieure au RTO.
    La Perte de Données Maximale Admissible, en anglais Recovery Point Objective (RPO) est la durée maximale entre la dernière sauvegarde d'une ressource et un incident majeur provoquant la perte des données. Elle quantifie les données que l'exploitation informatique peut être amenée à perdre.
    Concrètement, elle est déterminée par la fréquence et la nature des sauvegardes (ou réplications, ...) effectuées sur les ressources informatiques.
    Le RPO est utilisé dans le cadre de développement des Plans de Continuité d'Activité et Plans de Reprise d'Activité, de même que le Recovery Time Objective (RTO).
  • http://chaqual.free.fr/outils/amdec/histoireamdec.html
  • http://www.apachefrance.com/Articles/3/page1.html
  • Note: les tests se font aussi après la mise en prod
  • http://en.wikipedia.org/wiki/Fault_tolerant
    Fault-tolerance or graceful degradation is the property that enables a system (often computer-based) to continue operating properly in the event of the failure of (or one or more faults within) some of its components. If its operating quality decreases at all, the decrease is proportional to the severity of the failure, as compared to a naively-designed system in which even a small failure can cause total breakdown. Fault-tolerance is particularly sought-after inhigh-availability or life-critical systems.
  • la valeur d’usage : lorsqu’une application est indisponible, il y a une perte économique,
    la valeur d’image : la qualité de service participe à la satisfaction globale du client et contribue à créer une image positive,
    la valeur d’efficacité : l’entreprise optimise le fonctionnement nominal de ses processus ; la dégradation de la QoS entraîne une déviation par rapport au déroulement nominal qui se traduit par une perte de productivité.
  • Pourquoi externaliser : parce qu’on fait mieux si on fait souvent et en grand
    Dans la plupart des désastres qui ont été analysés, les problèmes qui sont à l’origine de la crise sont connus, et ont été bloqués par des raisonnements approximatifs ou des décisions douteuses de management : l’intégrité du professionnel des systèmes d’information consiste à ne pas laisser les messages d’alerte se perdre.
    La plupart des problèmes sont causés par des changements. Si le changement fait partie de la vie de l’entreprise, l’intégrité peut signifier savoir résister à un rythme qui n’est pas raisonnable.
    Les « règles de l’art » doivent être appliquées, la construction du plan de secours étant un parfait exemple. Les règles de l’art sont la seule protection contre la recherche d’un coupable lors d’une crise grave, puisqu’il n’existe pas de méthode absolue de fiabilisation.
    Les tests ne sont utiles que s’ils sont appliqués. Comme cela a été souligné, tous les ouvrages ou témoignages sur la fiabilisation, sans exception, insistent sur le rôle des tests. Il faut une véritable intégrité pour conduire les plans de test sous situation de stress liée au délai, et pour imposer le test de l’ensemble des composants, y compris le plan de secours.
  • Cours chapitre8 2012

    1. 1. Théorie et Pratique du Système d’Information Huitième Chapitre: QoS et Haute-Disponibilité Janvier-Mars 2012 Ecole Polytechnique Yves Caseau Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) 1/28
    2. 2. 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  Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) 2/28
    3. 3. Première Partie: Formalisation Fiabilité et Complexité  La fiabilité des SI est souvent incriminée:    Pourquoi ?    Les SI sont des systèmes complexes  Nombreuses interactions (cf. 1 SI = 1 Airbus) Les conséquences sont très importantes 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 Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) 3/28
    4. 4. 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). MTBF = MTTF + MTTR MTTR MTTF OK KO Disponibilité (%) temps Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) 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, … 4/28
    5. 5. Durée de vie et MTBF  La fiabilité évolue au cours du temps en fonction du cycle de vie: Durée de vie Fréquence des incidents jeunesse usure Période stable de définition du MTBF âge 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 » Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) 5/28
    6. 6. Fiabilité du matériel  Il existe une grande variabilité selon la qualité des composants et surtout selon l’architecture matérielle   Les fiabilités des matériels sont mesurées et publiées par les constructeurs.   Redondance à tous les niveaux (ex: alimentation) 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 12month 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) 6/28
    7. 7. Fiabilité du logiciel  Cycle    Fiabilité des composants    Software reliability metrics: taille et complexité  Liée à la qualité du processus de fabrication Fiabilité des assemblages    Fault/defect > error > failure Soft or hard failure: pb de la détection 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-8K Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) source: http://www.sei.cmu.edu 7/28
    8. 8. 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 »  Perte éventuelle de données Dernière sauvegarde Cause Durée de restauration des données Alerte : Effet : Dégradation Détection Analyse Diagnostic Action Réparation Restauration Si action insuffisante → boucle Si durée prévisionnelle est trop longue → Activation du Plan de secours Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) 8/28
    9. 9. 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:   RTO: Recovery Time Objective (DMIA) RPO: Recovery Point Objective (PDMA) Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) (a) Pertes (€) Probabilité indirectes productivité Directes (CA) Durée indisponibilité Incidents : Traitement quantitatif Crises : Traitement qualitatif Analyse probabiliste Étude de scénarios 9/28
    10. 10. 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)   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) 10/28
    11. 11. Plan de Secours (Disaster Recovery Plan)  PCA : plan de continuité d’activité    Composants:      Orienté processus métier Avec l’assistance et l’implication de la maîtrise d’ouvrage 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) 11/28
    12. 12. Deuxième partie Introduction à la Fiabilité  Fiabiliser le SI  SLA: Gérer la qualité de service  Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) 12/28
    13. 13. Deuxième Partie: Fiabiliser le SI Fiabilisation matérielle  Meilleure disponibilité:    Fiabiliser (cf. livre de Klaus Schmidt)    Augmenter le MTBF Réduire le MTTR (partie suivante) Robustesse Redondance = repetition + (replication + fault handling) Trois pistes:    Matériel fiable Matériel redondant (clusters) Architecture redondante Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) 13/28
    14. 14. Matériel Fiable  Cf. point précédent : les serveurs « haut-de-gamme » sont plus fiables (sauf exceptions)    Stockage   Technologies RAID (1 à 5) Importance du contrat de maintenance    HW dédié « fault-tolerant » (ex: Status): 99.999% 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) 14/28
    15. 15. Clusters  Redondance binaire    Avantages     Actif/passif Actif/actif 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) 15/28
    16. 16. Architectures 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 Ntiers    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) 16/28
    17. 17. Fiabilisation logicielle « Big Picture »: 3 approches  Test   Fault-tolerance et construction rigoureuse des applications    Éliminer le plus de défauts possible 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) 17/28
    18. 18. Tests Trois 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 # total anomalies Stock résiduel : détection (# anos) : détection (fréquence) seuil rentabilité marginale fin du test temps Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) 18/28
    19. 19. « Fault Tolerance » La qualité des applications joue un rôle essentiel (La Palisse)  Résister aux erreurs:    Détecter les erreurs / soft failures    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 Gestion des performances Auto-diagnostic Permettre une relance plus rapide   Recovery point (back-up) Démarrage rapide Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) 19/28
    20. 20. Redondance Logicielle 2 versions ne suffisent pas : comment savoir laquelle se « trompe » ? 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 » Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) 20/28
    21. 21. Dé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 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é   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) 21/28
    22. 22. Récupération Rapide  Schéma tiré de Marcus & Stern Days Hours Mins Secs Data Loss Secs Mins Hours Days downtime Tape Clusters Sync Replication Restore Manual or Mirroring Migration Async Replication Tape Back-up Periodic Replication  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é » Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) 22/28
    23. 23. Troisième Partie Introduction à la Fiabilité  Fiabiliser le SI  SLA: Gérer la qualité de service  Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) 23/28
    24. 24. SLA: Service 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) 24/28
    25. 25. Gestion économique du SLA incidents 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)   Pertes Coûts (€) La perte produite par les Coûts (€) 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 Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) Pertes Coûts Durée totale indisponibilité SLA théorique Coût total Coût de fiabilisation amélioration 98 % Coût de non-efficacité 100% disponibilité 25/28
    26. 26. 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     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) 26/28
    27. 27. Importance 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    Compétences sur le SI    Pourquoi externaliser : parce qu’on fait mieux si on fait souvent et sur des gros volumes Internaliser: pour développer une compétence propre 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) 27/28
    28. 28. Importance 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) SL Monitoring Incident Monitoring Alertes + stats + Processus métier BAM Diagnostic II.2 : Processus - Exploitation SLA Système fonctionnel SLA Système Applicatif erreur requêtes Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) Processus technique Système technique incident 28/28

    ×