Solutions

Solutions
INFORMATIQUE INDUSTRIELLE
Fiabiliser, ça
peut rapporter
gros! (1)
▼
La fiabilité est une discipline à part entière, qui sent bon les statistiques et est souvent jugée difficile à aborder. Dans ce premier article de la série consacrée à ce
sujet que nous démarrons ici, l’auteur Daniel Lelièvre (Factory Systèmes) s’est
efforcé de faire du concret et du pratique. Au-delà des indispensables définitions,
cet article d’introduction présente des situations concrètes de défaillances dues
à un manque de fiabilité. Les articles suivants aborderont davantage les solutions
qui permettent d’améliorer la disponibilité.
Q
uoi qu’on fasse, un jour ou
l’autre nos machines cassent
ou n’en font qu’à leur tête.
Plus elles sont complexes,
plus souvent ça arrive... La
perfection n’est pas de ce
monde, et encore moins du monde industriel.
C’est un fait. Nous subissons chaque jour les
coûts de la non-fiabilité de nos équipements,
des erreurs de ceux qui les conduisent ou
qui les ont conçus. Résultat, une part considérable des budgets
L’essentiel
attribués au fonctionnement normal de
Dans l’univers de la producl’exploitation est destition, les ordinateurs se voient
née à la résolution de
confier des tâches de plus en
plus importantes
situations “anormales”.
Du procédé lui-même
Les conséquences d’une
défaillance peuvent être draaux opérateurs qui le
matiques
pilotent, en passant par
Pour limiter les risques, il exisles machines et leurs
te des ordinateurs “pensés”
automatismes, ce sont
pour offrir une disponibilité
autant de déviations
élevée
potentielles qu’il nous
Pour faire les bons choix,
faut dompter.
poser les bonnes questions
et ne pas se laisser abuser, il
Acceptons le caractère
est préférable de bien s’iminéluctable et immiprégner des notions de base
nent de l’erreur ou de
de fiabilité
l’usure qui mène à la
46
défaillance.A l’aide de méthodes statistiques
aujourd’hui accessibles et éprouvées, calculons-en les probabilités d’occurrence, et
en face de ces probabilités, déterminons les
coûts induits. Nous pourrons alors décider
du bien fondé de la mise en place de
mesures préventives, lorsqu’elles existent,
et nous en comparerons les coûts à ceux de
mesures curatives.
Dans bien des cas, nous aurons la surprise d’afficher un retour sur investissement exprimé en semaines. Jules Renard
était de bon conseil : « Sous prétexte que la
perfection n’est pas de ce monde, ne gardez pas soigneusement tous vos défauts »…
L’informatique en première ligne
Lorsque nous faisons une analyse des
défaillances, nous concluons assez rapidement que certains éléments de notre outil
d’exploitation sont particulièrement critiques.
Au-delà des risques naturels, on trouve en
première ligne la distribution des énergies
et des fluides, les flux de matières premières,
et plus généralement, l’ensemble des facteurs
de “mode commun”, dont l’occurrence peut
affecter l’intégralité de l’outil de production.
La connaissance de ces risques “anciens”
appartient à la culture industrielle, et par
conséquent, leur traitement fait partie des
règles de l’art de l’ingénierie.
Il n’en va pas de même pour les risques
“nouveaux”, tels que ceux qu’engendrent
nos systèmes informatiques. L’évolution foudroyante de la technologie a doté nos outils
de production de moyens formidables. Ils
nous ont permis d’améliorer la qualité et la
sécurité des produits que nous fabriquons et,
notamment, notre productivité.Assemblages
souvent disparates -évolution oblige- de
composants informatiques, ces outils sont
d’une complexité inouïe, dont on ne maîtrise que la surface.
Mais toute médaille a son revers. Prenons le
cas des serveurs à base de PC. Paradoxalement, parce qu’ils sont plutôt fiables, nous
sommes mal préparés à leurs caprices. Et
l’on n’a sans doute pas tout vu! Initialement
conçus pour un usage personnel, peu critique, les PC se sont “infiltrés” aux postes
les plus critiques de nos entreprises. De plus,
les PC indépendants se sont petit à petit
ligués en réseau. Dans ces conditions, la
moindre défaillance est devenue porteuse
de coûteuses conséquences.
Certains PC ont été promus au rang de serveurs de fichiers ou de données potentiellement accessibles à tous. Le risque de
perte des données stockées dans ces
machines a motivé la création de disques
MESURES 761 - JANVIER 2004
Solutions
“miroir”, puis “RAID”, consistant à répliquer toute ou partie de l’information sur
plusieurs supports.
Enfin, et toujours pour faciliter l’administration de ces systèmes de plus en plus étendus, sont nées des architectures qui ressemblent à celles de nos anciens
mainframes : les serveurs d’applications.
Une machine puissante exécute l’ensemble
des fonctions du système, et des PC simplifiés à l’extrême se comportent comme
de simples terminaux opérateurs. Une
défaillance du serveur se traduit par la paralysie totale du système, pendant toute la
durée de la défaillance.
Dès lors, combien coûte la perturbation
engendrée par l’arrêt du serveur de courrier électronique qui gère les 2 500 boîtes
aux lettres du siège social ? Qu’advient-il
du contenu d’un réacteur dont on ne peut
poursuivre la conduite des opérations de
fermentation en cours ? Peut-on mettre
sur le marché les produits dont on n’a pas
conservé la trace de la production ?
Une approche souvent empirique
de la fiabilité
S’ils perçoivent aisément les avantages des
solutions qu’ils déploient, en termes de service rendu ou de facilité d’administration, les
services informatiques sont rarement équipés pour mesurer l’incidence de la défaillance de leurs installations, et la démarche de
fiabilisation, lorsqu’elle existe, est souvent
effectuée sur des bases empiriques.
Pourtant, la fiabilité est une discipline remarquablement maîtrisée. La sécurité des avions
ou des centrales nucléaires, la qualité de nos
téléphones portables ou de nos automobiles
ne sont que le résultat d’analyses de fiabilité
exhaustives qui ont dicté les choix technologiques des bureaux d’études.
Fiabiliser, c’est naviguer dans un domaine où la poutre qu’on a dans l’œil ne doit
pas nous empêcher de voir la paille dans
celui du voisin. La poutre, c’est par
exemple le logiciel de notre serveur qui
“plante” tous les six mois. La paille, c’est
son alimentation qui “lâche” une fois tous
les trois ans. Si nous attendons de résoudre
notre problème logiciel pour nous atteler
à celui de l’alimentation, il y a fort à parier
que ce dernier ne sera jamais résolu. Si
nous disposons d’une solution pour fiabiliser l’alimentation avec un ROI (retour
sur investissement) convenable, nous
devons la mettre en place immédiatement.
Nous aurons quoi qu’il arrive économisé
le coût d’un arrêt tous les trois ans.
MESURES 761 - JANVIER 2004
Les serveurs à haute disponibilité ne sont plus les “monstres”
d’antan.Ils prennent aujourd’hui le visage de PC sous forme de piédestal.
Les études sur la fiabilité s’appuient sur
des théories mathématiques. Avant de les
aborder, il faut bien assimiler le vocabulaire utilisé dans ce domaine et la définition de quelques termes fréquemment utilisés. Il faut très précisément savoir de quoi
l’on parle et les abus de langages, très fréquents, peuvent induire des erreurs d’interprétation.
Toute défaillance a pour origine une faute.
Nous parlerons par exemple d’une faute de
conception ou de la faute d’un opérateur. La
faute peut générer une erreur, et l’erreur
elle-même peut entraîner une défaillance.
A l’origine des défaillances,
les fautes…
Un programmeur se trompe, par exemple,
dans l’écriture d’une ligne de son code : il a
implanté une faute (qu’on qualifie de “dormante” si elle ne se manifeste pas immédiatement) dans son programme. Lorsque cette ligne de code est exécutée, elle écrit une
donnée erronée en mémoire : on est alors
en présence d’une erreur. Dès que l’utilisateur
accède à cette donnée, le système lui fournit une information erronée, et n’assure donc
pas son service conformément à ce qui lui
est demandé : c’est la défaillance.
Autre exemple. L’alimentation secteur de
notre serveur reçoit une impulsion dont la
tension excède les spécifications (la faute).
Cette impulsion détruit un composant, et la
tension délivrée à la carte mère n’est plus
correctement régulée (l’erreur). Le processeur
brûle après quelques heures de fonctionnement et c’est la défaillance du système.
Il existe de nombreux types de fautes.
Les fautes physiques. Il s’agit ici de fautes
survenant dans des conditions normales
d’utilisation. Exemples :
- Le composant “lâche” après avoir accompli
une longue carrière avec succès. Puisque le
composant ne subit pas d’usure à proprement
parler, cette défaillance “normale” du composant (erreur à l’échelle du système) est probablement due malgré tout à une faute, telle que
la présence d’une impureté dans le silicium.
- Le disque dur casse. Comme il est constitué
de pièces en mouvement, il s’use. La faute
est le choix des matériaux utilisés pour
concevoir le disque, même si aucun meilleur
choix n’était disponible. L’erreur, dans ce cas,
est inéluctable.
Les fautes externes. Il s’agit de fautes survenant dans des conditions anormales d’utilisation. Exemples :
- Une perturbation électromagnétique tra-
Quelques définitions
Selon toute vraisemblance, le système que
nous étudions a une utilité, que nous appellerons service. Lorsque le service est discontinu,
chaque période distincte de service sera appelée mission.
La disponibilité du système désigne son aptitude à délivrer le service, alors que sa fiabilité
désigne son aptitude à ne pas l’interrompre.
Une défaillance survient lorsque le service délivré diffère du service demandé. Dans certains
cas, notre système “refuse” d’assurer son service, dans d’autres, généralement plus graves, il
“décide” de faire autre chose que le service
demandé.
La sûreté de fonctionnement est l’aptitude à
éviter l’apparition de défaillances et à minimiser leurs effets lorsqu’elles se sont produites. La
sûreté comprend quatre composantes qui sont
la fiabilité, la maintenabilité, la disponibilité et
la sécurité.
47
Solutions
Les serveurs à haute disponibilité comportent plusieurs processeurs et des redondances.
Des méanismes permettent
de pallier toute défaillance,
en toute transparence pour
l’application.
verse le blindage que constitue le châssis de
notre serveur et entraîne la destruction d’un
composant.
- Un incendie ravage la salle informatique
- Un choc excédant la spécification a provoqué l’atterrissage brutal d’une tête sur la
surface d’un disque dur.
Les fautes de conception. Exemples :
- Le concepteur s’est trompé dans le calcul de
consommation de la carte mère. L’alimentation est sous-dimensionnée et n’atteindra
pas la durée de vie escomptée.
- Le programmeur s’est trompé dans son
analyse ou dans son codage. Que ce soit le
BIOS, le système d’exploitation, les pilotes
d’entrées/sorties ou les applications, notre
serveur est “truffé” de fautes logicielles. Ces
“bugs” peuvent dormir pendant des mois
ou des années sans que les circonstances ne
provoquent leur découverte.
- Des pilotes incompatibles avec la version
du matériel, la version du système d’exploitation ou les autres pilotes ont été installés. Les pilotes d’entrées/sorties, livrés avec
un matériel qui n’a généralement jamais été
testé dans un système strictement identique
sont à surveiller en particulier.
Les fautes d’interaction. Exemples :
- Un utilisateur insère une carte trop brutalement et endommage une des connexions
avec la carte mère.
- Le responsable de la maintenance effectue
une action de maintenance préventive en
ligne. Il débranche le mauvais connecteur et
provoque une défaillance.
- L’opérateur effectue une opération inappropriée.
- Le responsable de la maintenance détecte la
présence d’une erreur, avant que cette dernière ne se traduise par une défaillance. Il
choisit la mauvaise option de réparation et
provoque une défaillance. La faute est l’action
du responsable de la maintenance. Si ce dernier n’avait rien fait, on se serait sans doute
dirigé vers une autre défaillance.
Les intrusions. Exemples :
- Un utilisateur non autorisé parvient à entrer
dans le système et provoque une erreur.
- Le système reçoit un virus qui provoque
une erreur.
- Un utilisateur débranche volontairement
l’alimentation secteur.
MTTR, MTBF, etc.
Considérons l’exemple suivant : un serveur
de fichiers simple est rendu indisponible par
Et... ça arrive souvent ?
Qui peut se vanter de n’avoir jamais vécu la
défaillance d’un système ? Pourtant, à la
question “et, ça arrive souvent ?”, les utilisateurs répondent de manière incohérente :
celui qui vient de casser son disque dur peste
en prétendant que son PC n’est vraiment pas
fiable, alors que l’utilisateur d’une machine
identique qui “tourne” bien depuis cinq ans,
jurera qu’elle est “incassable”. Les deux ont
tort puisque ces deux machines sont dotées
du même niveau de fiabilité. La différence
n’est liée qu’au caractère aléatoire de la distribution des fautes.
Une démarche utile ne peut donc s’appuyer
que sur l’étude statistique des fautes, et
impose d’être en mesure de calculer la probabilité d’occurrence de la faute et de la
défaillance engendrée. Si nous savons com-
48
bien coûte l’arrêt et que nous connaissons la
fréquence de l’arrêt, nous obtenons un coût
annuel, en face duquel nous pourrons enfin
déterminer notre budget “fiabilisation”.
Les fiabilistes s’appuient sur des méthodes
rigoureuses, qui ont fait leurs preuves et qui
sont couramment utilisées, par exemple dans
la conception d’un aéronef ou d’une centrale
nucléaire. Elles ne permettent pas, nous le
savons déjà, de prédire à quel moment surviendra l’événement, mais elles nous indiqueront si l’architecture de tel système est
plus fiable que celle de tel autre. Enfin, elles
nous donneront une idée de la probabilité
que notre serveur s’arrête pendant les
6 heures nécessaires à la fabrication d’un lot,
probabilité qui se vérifiera d’autant plus que
le nombre de lots fabriqués est grand.
la défaillance de son alimentation. Cet incident entraîne l’impossibilité d’accéder aux
fichiers qu’il héberge et on considère donc
que le serveur n’assure pas son service. Dès
que l’alimentation défectueuse est échangée
et que le serveur est redémarré, le service est
à nouveau disponible. On souhaite chiffrer
le coût de l’incident, représenté par la perte
de productivité engendrée, à laquelle s’ajoutent le temps passé par le service maintenance et le coût de l’alimentation.
La perte de productivité liée à l’incident est
déterminée par le coût de l’indisponibilité
du service, coût qui est évidemment fonction
de la durée de l’arrêt du serveur. C’est ce
temps qu’il nous faut donc déterminer en
premier lieu, à partir de quelques éléments
de fiabilité, dont il faut connaître la signification.
MTTF et Taux de Défaillances. A partir
d’une “ population” de composants identiques qu’on laisse fonctionner sans limite
de temps, on aboutira inévitablement à la
situation où tous nos composants seront
défaillants (puisque rien n’est éternel...). Si
l’on ne peut prédire à quel instant se produira la défaillance de chacun d’eux, on sait
par contre calculer, à partir de la mesure de
la durée de vie de chacun, leur “temps
moyen jusqu’à la défaillance”. Entre deux
populations de composants identiques, on
observe que cette moyenne est constante,
d’autant plus que le nombre d’échantillons
constituant les populations est important.
La plupart des constructeurs de systèmes
publient des données de fiabilité de leurs
équipements, qu’ils ont calculées à partir des
données de fiabilité que leur ont communiquées leurs propres fournisseurs de composants. La donnée qu’ils fournissent est
généralement exprimée en MTBF (Mean Time
Between Failure), temps moyen entre
défaillances, donné en heures ou en années.
Il s’agit d’un abus de langage et il conviendrait de parler de MTTF (Mean Time To Failure),
temps moyen jusqu’à la défaillance, ou
temps moyen de bon fonctionnement.
Dans le cas de notre serveur de fichiers, le
constructeur nous a annoncé un MTTF de
30000 heures, soit environ 3,4 années (une
année ordinaire comporte 8760 heures).
Cette donnée peut encore être exprimée en
taux de défaillances par heure (Failure Rate),
que l’on peut approcher par :
λ≈
1
MTTF
Cette approximation est applicable à des
éléments dont le taux de défaillance est
constant (ce qui est le cas de la grande
MESURES 761 - JANVIER 2004
Solutions
majorité des composants électroniques).
Du fait de la faiblesse des valeurs de λ, le taux
de défaillances est souvent exprimé en FITS
(Failure In Time), où 1 FIT = 1 défaillance par
milliard d’heures.
Nous pouvons donc quantifier la fiabilité de
notre serveur comme suit :
λserveur = 3,3333*10-5déf/h = 33333 FITS
MTTR et Taux de Réparation. A supposer
que notre serveur de fichiers soit réparable,
cette intervention ne peut bien évidemment
pas être instantanée. Le temps moyen de
réparation, que l’on exprime en heures, est
appelé MTTR (Mean Time To Repair).
On doit estimer, en fonction du contexte de
l’application, le temps moyen total qui sépare l’apparition de la défaillance de la remise
en service actif. On prendra en compte l’ensemble des paramètres pouvant influencer
le temps de réparation, à commencer par les
moyens de détection et d’information de
l’équipe de maintenance. Si un système de
diagnostic évolué envoie un SMS sur le portable du technicien d’astreinte, ce dernier
pourra peut-être intervenir avant même
qu’un utilisateur du service ne s’aperçoive
de son indisponibilité (avant donc l’apparition de la défaillance).
Sans qu’un savant calcul ne soit nécessaire,
on décèle aisément l’impact du MTTR sur les
coûts liés à l’indisponibilité du service rendu, et le choix d’une stratégie de maintenance est aussi critique que celui de la technologie du système.
Notons cependant que de nombreux
constructeurs de systèmes réparables utilisent un MTTR présumé de 8 heures dans
leurs études de fiabilité, héritage du temps
où les systèmes étaient simples... Nous verrons plus loin que le MTTR “réaliste” d’un
serveur peut-être bien supérieur.
De la même façon que nous avons calculé le
taux de défaillances à partir du MTTF, nous
pouvons calculer le taux de réparation à partir du MTTR que nous admettrons pour l’instant de 8 heures :
µ=
1
1
=
= 0,125
8
MTTR
MTBF. Dès lors qu’on connaît le MTTR et le
MTTF, nous pouvons calculer le MTBF (Mean
Time Between Failure), temps moyen entre
défaillances, puisque deux défaillances consécutives supposent une réparation intermédiaire :
MTBF = MTTR + MTTF
Notre serveur de fichiers aurait donc un
MTBF de 30008 heures, très voisin du MTTF.
Cette similitude explique la confusion fréquente entre MTTF et MTBF, et l’abus de lanMESURES 761 - JANVIER 2004
gage commis par les constructeurs. Ces derniers ne peuvent bien évidemment pas préjuger du MTTR réel, puisqu’ils n’en contrôlent qu’une partie minime (accessibilité,
interchangeabilité, approvisionnement du
composant).
Disponibilité et indisponibilité.Afin d’évaluer l’impact annuel des défaillances du serveur, nous devons déterminer sa disponibilité, aptitude à délivrer le service, exprimée
en pourcentage du temps total, ou, de manière plus académique “mesure de l’alternance entre service rendu et interruption de service”. La disponibilité A (availability) est
donnée par la relation :
A=
MTTF
= 1- MTTR
MTTF + MTTR
MTBF
Inversement, l’indisponibilité (Unavailability) Q, sera exprimée par :
Q = 1 - A = MTTR
MTBF
A partir des valeurs utilisées précédemment,
notre serveur est disponible 99,973 % de la
période considérée, et est indisponible le reste du temps, soit 0,027 % du temps
(142 minutes/an).
Taux de Défaillances d’une population.
Nous savons maintenant évaluer l’indisponibilité annuelle d’un serveur. Cependant,
certains de nos ateliers reposent sur plusieurs
serveurs, et l’indisponibilité de l’un d’entre
eux suffit à rendre l’atelier inopérant. Pour
calculer l’indisponibilité annuelle de l’ensemble constitué par trois serveurs, par
exemple, nous ajouterons tout simplement
leurs taux de défaillance respectifs, ce qui
nous fournira le taux de défaillance de l’ensemble. Ainsi, si le MTTF de chaque serveur
est respectivement de 30 000 heures,
15000 heures et 20000 heures, on obtient :
λserveur =3,33x10-5 +6,66x10-5 +5x10-5 =1,5x10-4
soit un MTTF global de 6 666 heures, ou
environ une défaillance tous les 9 mois.
Encore une fois, ce calcul ne nous permet
en aucun cas de prédire à quel moment
chaque serveur nous laissera tomber. Ce dont
nous sommes sûrs, en revanche, c’est que
sur nos trois machines, nous pouvons nous
préparer à en réparer en moyenne 1,3 par
an, et qu’au total, nos utilisateurs seront perturbés pendant plus de 10 heures dans l’année...
Fiabilité de mission. Maintenant que nous
savons manipuler ces données simples, nous
devons nous poser une question importante : recherchons-nous la disponibilité de l’équipement ou plutôt sa fiabilité?
La rupture d’une caténaire entraîne, pour le
Paramètres
Valeurs
MTTF
λ Serveur (taux de défaillance)
λ Serveur (FITS) (taux de défaillance)
MTTR
µ (taux de disponibilité)
MTBF
A (disponibilité)
Q (indisponibilité)
Q (h/an)
30000
3,33E-05
33333
8
0,125
30008
99,973 %
0,027 %
2,37
A partir du MTTF fourni par le constructeur,et du MTTR estimé,
il est possible de calculer tous les autres paramètres
train qui emprunte cette voie, un arrêt dont
la conséquence est principalement fonction
de la durée. Pour réduire l’impact de ce type
d’incident, l’exploitant pourra investir sur
deux axes :
Une longue expérience
Factory Systèmes a depuis longtemps une culture
de la haute disponibilité, qu’elle a acquise notamment à travers les marques prestigieuses Triconex
et Moore. La gamme ftServer de Stratus qu’elle
commercialise aujourd’hui s’inscrit dans cette
continuité.
Cette gamme assure une disponibilité supérieure à
99,999% et se décline en trois modèles : le modèle
3300 (1 ou 2 processeurs Intel Xeon 2,4 GHz), le
modèle 5240 (1 ou 2 processeurs Intel Xeon 2,8 GHz)
et enfin le modèle 6500 (1 à 4 processeurs Intel Xeon
MP 2 GHz). Le modèle 6500 est selon Factory Systèmes le seul serveur multi-traitement 4 voies à tolérance de pannes de l’industrie pour les environnements Windows.
Sur ces serveurs, les composants matériels à tolérance de pannes répliqués traitent les mêmes instructions au même moment. En cas de dysfonctionnement d’un composant, le composant
associé joue le rôle de pièce de rechange assurant le fonctionnement normal. Il n’y a ni interruption ni perte de données.
Ces serveurs disposent, selon les modèles, de 20 à 28
emplacements pour disques durs de 18 à 73 Go.
Ils peuvent gérer, selon les modèles, jusqu’à 4 ou
12 liaisons Ethernet 1000 Base-T.
Le modèle 3300 est proposé en format piedestal
ou rack 3U, le modèle 5240 en rack 16U et enfin le
modèle 6500 en rack 16U ou 18U. Tous fonctionnent sous Windows2000 Advanced Server et sont
prêts à accueillir le futur Windows Server 2003.
49
Solutions
- améliorer la caténaire, dans les limites
imposées par les possibilités technologiques
et économiques, ce qui augmentera son
MTTF et réduira son λ,
- réduire le temps d’intervention des équipes
de maintenance et améliorer leur efficacité,
ce qui réduira le MTTR.
La défaillance d’un moteur d’avion, au
roulage, est en principe sans conséquence grave. Elle n’entraînera qu’une perte
d’exploitation liée à la nécessité de réparer. Par contre, dès que l’aéronef est en
phase de décollage ou en vol, la défaillance du moteur peut s’avérer dramatique.
Dès que la mission est commencée, et
pendant toute sa durée, le moteur doit
fonctionner. Le constructeur de l’avion ne
peut travailler que sur un seul axe : fiabiliser le moteur pour qu’il soit capable
d’assurer sa mission.
La réparation du moteur est, non seulement impossible pendant la mission, mais
surtout inutile, puisque “le mal est fait”
dès l’apparition de la défaillance. On parle alors de “fiabilité de mission”, pour
laquelle l’amélioration du MTTR n’a aucun
50
effet. On peut calculer cette dernière par
l’application de la formule :
R(t) = e-λxt
où R, la fiabilité, est la probabilité que notre
équipement assure la mission de durée t sans
défaillance et λ le taux de défaillance.
Prenons l’exemple d’un serveur qui collecte des données pendant la fabrication d’un lot
d’un produit pharmaceutique. Le fabricant
ne peut vendre son produit que s’il est en
mesure de fournir la trace des opérations de
production de ce dernier.
Une défaillance du serveur intervenant entre
deux fabrications n’entraînera qu’un retard
dans la production s’il n’est pas réparé à
temps. Une défaillance du même serveur
pendant l’exécution de la mission peut
entraîner la perte pure et simple du lot en
cours de fabrication. En supposant que la
fabrication d’un lot dure 72 heures et que
le taux de défaillances du serveur soit de
3,3333*10-5, la probabilité que notre serveur assure sa mission sans défaillance est :
-5
R(t) = e-3,3333x10 x72 = 0,997603
Nous aurions pu obtenir un résultat très
approchant, en calculant la disponibilité d’un
tel système. Puisque nous ne pouvons exercer de réparation pendant la durée de la mission, nous utiliserons un MTTR égal à la durée
de la mission :
λ≈
1
MTTF
⇒MTTF ≈ 1 ≈ 30000
λ
30000
=
=0,997606≈R(t)
MTTF + MTTR 30000+72
On admettra donc que la fiabilité de mission
d’un système est approchante de sa disponibilité calculée avec un MTTR égal à la durée
de la mission.
Daniel Lelièvre
Factory Systèmes*
[email protected]
A=
MTTF
*Factory Systèmes
22, rue Vladimir Jankelevitch
Emerainville
77437 Marne la Vallée Cedex 2
Tél.: 01 64 61 68 68 - Fax: 01 64 61 67 34
MESURES 761 - JANVIER 2004
Solutions
INFORMATIQUE INDUSTRIELLE
Fiabiliser, ça
peut rapporter
gros! (2)
▼
La fiabilité est une discipline à part entière, qui sent bon les statistiques et est souvent jugée difficile à aborder. Dans ce deuxième article de la série consacrée à ce
sujet, l’auteur Daniel Lelièvre (Factory Systèmes) aborde plus particulièrement la
notion de la redondance et l’amélioration qu’elle apporte en terme de disponibilité du système. Comme pour l’article précédent, cet article se veut didactique et
pratique.
A
partir des données de fiabilité
des composants qu’il utilise,
il est possible de calculer les
données de fiabilité d’un
équipement, et plus particulièrement son
MTTF (Mean Time To Failure), temps moyen jusqu’à la défaillance, ou encore temps moyen
de bon fonctionnement. Les constructeurs
de matériels pour applications pointues font
ce type de calcul et fournissent la valeur du
MTTF ou du taux de
défaillance. Le MTTF
L’essentiel
fourni correspond
Dans l’univers de la probien entendu à une
duction, les ordinateurs se
configuration
“usine”
voient confier des tâches
typique. Mais sur le
de plus en plus importerrain, il arrive frétantes
Les conséquences d’une
quemment que l’on
défaillance peuvent être
ait besoin de modifier
dramatiques
la configuration. Par
Pour limiter les risques, il
exemple, pour un serexiste des ordinateurs
veur de fichiers, on
“pensés” pour offrir une
disponibilité élevée
pourra être amené à
Ceux-ci comportent des
ajouter un deuxième
redondances qui en améprocesseur, 2 disques
liorent la disponibilité
durs et 3 barrettes
Mais les redondances ont
mémoire. Le MTTF
un coût. Pour les justifier,
ce coût doit être comparé
fourni par le construcaux coûts de risques de
teur du système n’est
pertes de production ou de
évidemment plus
pertes de données
valable puisqu’il ne
46
correspond pas à la configuration pour lequel
il a été calculé.
Mais le MTTF du système modifié peut être
calculé. Pour cela, faisons l’hypothèse que la
défaillance d’un seul de ses composants suffit à entraîner une panne du serveur, et son
arrêt pour réparation1. De ce fait, lorsque
l’on ajoute des composants à notre serveur,
il suffit d’ajouter à son taux de défaillance
“usine” le taux de défaillance de chacun des
composants ajoutés et, à partir de là, calculer le nouveau MTTF (pour les composants
et équipements électroniques, c’est facile, le
MTTF est égal à l’inverse du taux de défaillance). Et c’est ainsi que pour un serveur qui
affiche un MTTF de 30000 heures au départ,
l’ajout d’un deuxième processeur, de deux
disques durs et trois barrettes mémoire se
traduit par une chute du MTTF à
24813 heures.
Le temps de réparation dépend
du type de panne
Le MTTF est une chose, le temps moyen de
réparation (MTTR) en est une autre. Ici aussi, tout doit être pondéré en fonction du type
de composant défaillant, et de son impact.
Nous savons qu’une défaillance peut avoir
des conséquences très variables en fonction
de la mission confiée au système. Nous
devons aussi nous préoccuper du fait qu’à
l’intérieur de notre système, certains composants sont plus critiques que d’autres. Le
mode de défaillance de notre système variera selon le composant défaillant. La perte
d’une carte réseau, par exemple, n’aura pas
le même impact que la perte d’un disque
dur (et des données qu’il contient).
Dans le premier cas, le temps d’échanger la
carte se traduira par une simple indisponibilité du service. Dans le second, non seulement notre MTTR est considérablement augmenté (il nous faudra prendre le temps de
restaurer les données), mais, comme notre
dernière sauvegarde n’est pas strictement à
jour, il nous faudra estimer le coût de la perte (ou de la reconstruction) de ces données.
Nous devons donc calculer un MTTR “système” à partir de MTTR composants différents.
Il suffit d’effectuer la somme des taux de
réparation (µ) de chacun des composants,
pondérées par leur taux de défaillance (λ), ce
qui nous fournit le taux de réparation du
système, et le MTTR par son inverse.
De plus, puisqu’on recherche un MTTR “système” réaliste, on en profitera pour décomposer ce dernier, pour chaque composant,
afin de refléter :
- le temps moyen d’intervention (le temps
nécessaire aux équipes de maintenance pour
se rendre sur le site).
- le temps d’échange du composant (pour
MESURES 762 - FEVRIER 2004
Solutions
le disque dur, on aura tenu compte du temps
de réinstallation ou de restauration du contenu).
En tenant compte du fait que le MTTR varie
d’un composant à l’autre et surtout en prenant pour chacun d’eux un MTTR “réaliste”, le MTTR global (donc au niveau système) se dégrade et la disponibilité2 du
système est plus faible. Mais cette approche
est, de toute évidence, plus réaliste que celle qui résulte d’un calcul à MTTR constant.
Comment se protéger des fautes ?
Puisque toute défaillance a pour origine une
faute, et que nous sommes maintenant en
mesure d’en déterminer l’impact, il est probable que nous percevions l’intérêt de nous
en préserver.
En fait, peut-être sans le savoir, nous sommes
en quête de plus de sûreté de fonctionnement, propriété d’un système qui permet
de placer une confiance justifiée dans le service qu’il
délivre. Pour y parvenir, nous devrons certainement choisir ou combiner plusieurs axes
de protection contre les fautes.
L’évitement des fautes. Il s’agit là d’empêcher, méthodologiquement, l’apparition de
fautes dans le système.
- en utilisant des systèmes standards, à base
de composants standard, on réduira par définition les risques de fautes de conception.
- en choisissant des composants fiabilisés, en
améliorant leurs conditions de fonctionnement (thermiques et électromagnétiques
entre autres), en protégeant les sources possibles de perturbations (alimentations, liaisons), on réduira les risques de fautes physiques ou externes.
- en utilisant des matériels et logiciels connus
des utilisateurs, en n’effectuant que la maintenance préventive des composants qui l’imposent, en automatisant les interventions à
chaque fois que c’est possible, en donnant
aux opérateurs des interfaces non ambiguës,
on réduira les risques de fautes d’interaction.
L’élimination des fautes. Les fautes sont
détectées et corrigées avant qu’elles ne soient
susceptibles de générer des erreurs.
On préférera l’utilisation de protocoles de
communication sécurisés où la faute dans
une trame véhiculée sur le réseau sera détectée avant que la trame ne soit traitée, puis réémise jusqu’à ce que l’on obtienne une trame exempte de faute.
La tolérance aux fautes. On admet (tolère)
la présence de fautes au sein du système, mais
on met en œuvre des mécanismes (généralement basés sur la redondance), capables de
“couvrir” (étouffer, masquer) ces fautes.
- La redondance est la méthode la plus simple
pour tolérer les fautes. Elle peut s’exercer sur
une partie du système (redondance partielle) ou
sur sa totalité (redondance massive).
Bon nombre de constructeurs ont recours à
la redondance partielle, plus économique.
Après avoir identifié les fonctions les plus
critiques du système (par l’étude de la fréquence et de la gravité des défaillances), on
confie à un sous-système une partie de la
mission du serveur (alimentations doublées,
disques miroirs ou RAID...).
Cette approche fonctionne bien tant que ces
redondances sont prévues dans la conception même des systèmes. Les redondances “
maison”, où, par exemple, un “mini-serveur” assure le secours du serveur principal,
se heurteront inévitablement à des problèmes
d’évolutivité.A la mise en service, il est probable qu’ils soient à même de jouer leur rôle
mais, après quelques années d’évolution, de
migrations ou mises à jour, le simple coût
Quelques rappels
Dans l’article précédent, nous avions défini un
certain nombre de termes, que nous vous rappelons ici :
MTTF : Temps moyen jusqu’à la défaillance
MTTR : Temps moyen de réparation
MTBF : Temps moyen entre défaillances
λ : Taux de défaillance
µ : Taux de réparation
Disponibilité : aptitude à délivrer le service
Indisponibilité : contraire de la disponibilité
…et quelques formules
λ=
1
MTTF
(formule applicable à des éléments dont le taux
de défaillance est constant, ce qui est le cas des
composants électroniques)
µ=
1
MTTR
MTBF = MTTF + MTTR
MTTF
Disponibilité =
= 1-
MTTF + MTTR
MTTR
MTBF
Indisponibilité = 1 – Disponibilité =
MTTR
MTBF
des campagnes de tests garantissant le fonctionnement correct de la stratégie de redondance aura dépassé le surcoût d’une redondance massive.
Evaluation de la disponibilité d’un serveur
Quantité
λ
λ total
MTTR (réaliste)
µ (réaliste)
1
6,25.10-6
6,25.10-6
14 h
7,14.10-2
CPU
2
5,71.10-7
1,14.10-6
10 h
1,00.10-1
Alimentation
1
1,00.10-5
1,00.10-5
11 h
9,09.10-1
Disque dur
8
2,00.10-6
1,60.10-5
16 h
6,25.10-2
Mémoire (256 Mo)
4
7,99.10-7
3,20.10-6
10 h
1,00.10-1
1
1,00.10-6
1,00.10-6
10 h
1,00.10-1
Composant
Carte Mère
Carte Réseau
λ = 3,76.10-5
Système
µ = 7,69.10-2
MTTF = 1/λ = 26 604 heures
MTTR = 1/µ= 13 heures
MTBF=MTTF+MTTR=26 617 heures
Disponibilité =
A partir du taux de défaillance (λ) des éléments fournis par le
constructeur,et du MTTR estimé,il est possible de calculer tous les
autres paramètres.
MESURES 762 - FEVRIER 2004
MTTF
MTTF+MTTR
= 99,951 %
Indisponibilité = 1 – Disponibilité = 0,049 % = 0,049.10-2x8 760* = 4,3 heures/an
1 an = 8 760 heures
47
Solutions
- La redondance peut être d’ordre n, c’est-àdire que le nombre de sous-systèmes destinés à couvrir la faute d’un autre sous-système peut être supérieur à 1. La redondance
la plus simple est d’ordre 2 (deux sous-systèmes se contrôlent et se couvrent mutuellement).
- Un système redondant peut être composé
de sous-systèmes identiques (redondance homogène) ou différents (redondance hétérogène). La
redondance hétérogène affranchit la redondance des fautes de modes communs, celles
qui peuvent affecter simultanément plusieurs
sous-systèmes.A l’extrême, on peut imaginer
deux sous-systèmes basés sur des platesformes différentes dotées de systèmes d’exploitation différents, exécutant des pro-
grammes écrits dans des langages différents...
De telles architectures ne sont envisageables
que pour des applications stables, répétitives
et hautement critiques, les coûts de développement, et surtout de maintenance, étant
généralement prohibitifs.
- Les sous-systèmes peuvent être synchrones ou
asynchrones. Les sous-systèmes asynchrones
sont, là encore, moins sensibles à des fautes
de mode commun telles que les perturbations électromagnétiques.
La redondance, protection totale ?
On aimerait que l’adoption des redondances
rende nos systèmes infiniment fiables, mais
cette notion n’a pas droit de cité dans le vocabulaire du fiabiliste. Quelles que soient les
mesures prises, il restera une probabilité pour
que notre système s’écarte un jour de sa mission. Les causes peuvent être multiples.
Mode commun. Tout système redondant
reste exposé aux fautes dites de mode commun.
Il s’agit de celles qui peuvent affecter les n
sous-systèmes simultanément. Les perturbations électromagnétiques, par rayonnement
ou par conduction, les risques naturels ou
l’erreur humaine sont autant de sources possibles de fautes de mode commun contre
lesquelles un système redondant peut s’avérer impuissant.
Couverture. Aucun système redondant ne
peut garantir que toutes les fautes affectant un
sous-système seront couvertes. Il existe une
probabilité pour que, lors de l’occurrence
Les graphes de Markov pour
P
coûteux. Il est donc intéressant de voir, pour un faible investisseour faciliter l’analyse d’un système avec redondances et
ment, s’il n’est pas possible d’améliorer de façon substantielle le
l’impact des défaillances, un bon moyen est de comtaux de défaillance du système.
mencer par modéliser son comportement, en utilisant
Probabilité de quitter l’état normal (PSOK). Si l’on considère que
les graphes dits de Markov. Rappelons que Andreï
le système est en état normal de fonctionnement “système OK” (PSOK
Andreïvitch Markov, mathématicien et poète russe, a réalisé au
début du siècle dernier d’importants travaux sur les processus sto- ”), la probabilité qu’il a, dans l’heure en cours (si on prend, par
convention t = 1 heure), de quitter cet état est liée à :
chastiques (aléatoires) et leurs enchaînements. Il a proposé une
- la défaillance de l’une des deux alimentations (soit deux fois le
théorie permettant de calculer le comportement d’un système de
probabilités complexe, à partir d’un modèle graphique.A ce jour, taux de défaillance d’une seule alimentation) pondéré par le taux
de couverture CAL, qui nous amène à l’état “1 alim HS”(PALHS):
les graphes de Markov sont utilisés principalement par les fiabiPSOK → PALHS = 2λALCAL
listes dans l’étude des systèmes réparables, pour lesquels d’autres
méthodes telles que les arbres de défaillances
sont moins bien adaptées.
Nous allons appliquer cette méthode à un
serveur tel que celui que nous avons vu,
mais auquel on a ajouté une seconde alimentation, connectée de telle sorte que la
défaillance de l’une est masquée par la
seconde, et que l’alimentation défaillante
puisse être échangée en ligne (“à chaud”).
Une telle étude est intéressante car l’alimentation est l’élément le plus fragile (λ = 1.10- Chaque ovale représente un “état”du système,ou plus précisément,la probabilité qu’a le système de se trouver dans cet état pendant une
5) d’un système et c’est aussi un des moins période de temps t.Chaque flèche représente la probabilité de passer d’un état à un autre pendant la même période.
Configuration du système
Composant
Carte mère
CPU
Alimentation
Disque dur
Mémoire (256 Mo)
Carte Réseau
Nombre
1
2
2 (en redondance)
8
4
1
Plus le système comporte d’éléments,plus son MTTF va baisser
(voir tableau “Evaluation de la disponibilité d’un serveur informatique”).Par contre,si un des éléments est en redondance,comme c’est le cas ici pour les alimentations,le MTTF va remonter.
48
Etats du système
PSOK → PALHS
Probabilité qu‘a le système de passer de l‘état “OK” (avec les deux alimentations en état de marche)
à l‘état “1 alim HS”
PSOK → PSHS
Probabilité qu‘a le système de passer de l‘état “OK” à l‘état “HS”
PSOK
Probabilité qu‘a le système de rester à l‘état “OK” (état normal de fonctionnement)
PALHS →PSOK
Probabilité qu‘a le système de passer de l’état “1 alim HS” à l’état “OK”
PALHS → PSHS
Probabilité qu‘a le système de passer de l‘état “1 alim HS” à l‘état “HS”
PALHS
Probabilité qu‘a le système de rester à l‘état “1 alim HS”
PSHS →PSOK
Probabilité qu‘a le système de passer de l‘état “HS” à l‘état “OK”
PSHS
Probabilité qu‘a le système de rester à l‘état “HS”
MESURES 762 - FEVRIER 2004
Solutions
d’une faute sur un sous-système, le ou les
autres sous-systèmes soient incapables de
“masquer” cette dernière. Son complément
à 1 est le taux de couverture. Si, par exemple, une
alimentation défaillante génère une tension
de sortie trop élevée, une seconde alimentation simplement connectée en parallèle par
un jeu de diodes n’aurait aucun moyen de
couvrir la tension anormalement élevée. A
supposer qu’un tel mode de défaillance de
l’alimentation se produise dans un cas sur
dix, la seconde alimentation pourra couvrir
la faute de la première 9 fois sur dix, et le
taux de couverture de la redondance sera de
90 %.
Stratégie de maintenance. L’efficacité de la
redondance reste avant tout conditionnée par
une stratégie de maintenance adaptée. Si un
sous-système assure la redondance d’un autre
sous-système, le système n’est tolérant aux
fautes que lorsque les deux sous-systèmes
sont en service (pour une redondance
d’ordre 2). Sur défaillance de l’un d’entre
eux, le système, bien qu’opérationnel, perd
sa tolérance aux fautes, et est alors vulnérable
à la première défaillance. On doit donc :
- assurer sa réparation dans les meilleurs
délais (disposer des moyens humains, matériels et logiciels).
- comprendre et s’organiser en fonction de
la nature différente des opérations de maintenance sur un système tolérant aux fautes.
Lors de la défaillance d’un système non
redondant, le système à réparer n’assure plus
son service, et les opérations de maintenance s’effectuent “à froid”, sans autre risque, a
priori, que de retarder le redémarrage. La
réparation d’un système tolérant aux fautes
s’effectue “à chaud”, et le risque d’interrompre le service délivré est évident. Il s’agit
donc de choisir le meilleur compromis entre
intervenir le plus rapidement possible et
intervenir avec le personnel compétent.
Combien coûte la non-fiabilité ?
A partir des informations de fiabilité, nous
pouvons déterminer le coût de la non-fiabilité d’un serveur, en fonction de l’application à laquelle il est destiné et du type de
préjudice causé en cas de panne. Nous nous
intéressons ici à un système de supervision
étudier un système redondant
- la défaillance d’un autre composant (carte mère, CPU, disque
dur, mémoire ou carte réseau), dont les taux de défaillances
s’ajoutent (λCM + 2λCPU + 8λDD + 4λM +λCR), ou la défaillance
“simultanée” des deux alimentations (2λALCAL.λAL = 2λ2ALCAL) ou
encore la défaillance non couverte d’une des deux alimentations
[λAL.(1- CAL]. Dans toutes ces situations, nous irons directement à
l’état “système HS”(PSHS):
PSOK → PSHS = λCM + 2λCPU + 8λDD + 4λM +λCR +2λ2ALCAL +
2λAL.(1- CAL)
Probabilité de rester à l’état normal (“Système OK”). La probabilité PSOK qu’a le système de rester à l’état “système OK” est donc égale à :
PSOK = 1 – Probabilité de quitter l’état PSOK
Probabilité de quitter l’état “1 Alim HS”. En poursuivant ce
même raisonnement, la probabilité de quitter l’état “1 alim HS”,
dépend de :
- la réparation de l’alimentation défaillante, dont la probabilité est
égale à son taux de réparation µAL, qui permet de revenir à l’état
“Système OK” :
PALHS→ PSOK = µAL
- la défaillance de la seconde alimentation ou d’un quelconque autre composant du système, qui nous mène à l’état
“Système HS” :
PALHS→ PSHS = λCM + 2λCPU + 8λDD + 4λM +λCR+λAL
Probabilité de rester à l’état “1 alim HS”. Celle-ci est donc égale à :
PALHS = 1 - Probabilité de quitter l’état PALHS
Probabilité de quitter l’état “HS” pour revenir à l’état “OK” :
PSHS → PSOK = µS
Probabilité de rester à l’état “système HS”. Celle-ci est conditionnée par la probabilité de réparation système µS :
PSHS = 1 - µS
Calcul du MTTF système. Nous voyons que le calcul de la probabilité de quitter un état donné, ou d’y rester, est très simple
dès que nous avons modélisé le comportement du système.
Cependant, ce que nous recherchons réellement, c’est la probabilité d’atteindre l’état “système HS” à partir de l’état “système
OK”, probabilité qui nous fournira le MTTF système.
Pour y parvenir, nous devrons nous livrer à un exercice de
calcul un peu plus complexe, qui repose notamment sur du
calcul
matriciel.
Nous ne les présen- Valeurs calculées
terons pas ici.
PSOK →PALHS
1,8.10-5
Signification et valeurs des symboles utilisés
λCM
λCPU
λAL
λDD
λM
λCR
CAL
λAL (1 – CAL)
2 λALCAL. λAL = 2 λ2ALCAL
µAL
µS
Taux de défaillance du composant “Carte Mère”
λCM = 6,25.10-6
Taux de défaillance de la CPU
λCPU =5,71.10-7
Taux de défaillance du composant “Alimentation”
λAL =1,00.10-5
Taux de défaillance du composant “Disque Dur”
λDD =2,00.10-6
Taux de défaillance du composant “Mémoire”
λM =7,99.10-7
Taux de défaillance de la carte réseau
λCR =1,00.10-6
Taux de couverture du système de redondance de
On se fixe ici CAL = 90 % (le système de
l‘alimentation
redondance couvrira 9 défaillances sur 10)
Défaillance non couverte d’une des deux alimentations
1.10-6
Défaillance simultanée des deux alimentations
1,8.10-10
Taux de réparation de l’alimentation
µAL = 9,09.10-1 (MTTR = 11 heures)
Taux de réparation du système
µS = 7,69.10-2 (MTTR = 13 heures)
MESURES 762 - FEVRIER 2004
PSOK →PSHS
2,9588.10-5
PSOK
0,9999524
PALHS →PSOK
9,09.10-2
PALHS →PSHS
3,7588.10-3
PALHS
0,90905332
PSHS →PSOK
7,69.10-2
PSHS
0,9231
MTTF = 33795 heures
Disponibilite =
MTTF
MTTF+MTTR
= 99,96152 %
Indisponibilité = 1 – Disponibilité = 0,03848 %
= 0,0348.10-2x8760* = 3,4 heures/an
* 1 an = 8 760 heures
49
Solutions
Comparaison des indisponibilités d’un serveur classique
et d’un serveur avec alimentation redondante
Perte par indisponibilité du service
Serveur standard
Alimentation doublée
Perte de données
Serveur standard
Alimentation doublée
Perte par interruption
de la mission
Serveur standard
Alimentation doublée
Fréquence Heures perdues
sauvegarde par incident
24 h
12
Coût / heure
Heures perdues / an
Coût annuel
10 000 €
4,3
3,4
Gain
42 815 €
33 708 €
9 107 €
Coût / heure
Heures perdues / an
Coût annuel
30 000 €
1,7 h
1,7 h
Gain
50 458 €
50 458 €
0€
Durée
mission
Coût par lot
Nombre de lots
fabriqués par an
Coût par lot
Coût annuel
72 h
200 000 €
100
540 €
425 €
53 981 €
42 519 €
11 462 €
Gain
Investissement
500 €
ROI*
20 jours
Investissement
500 €
ROI*
n/a
Investissement
500 €
ROI*
15 jours
*ROI : return on investment, retour sur investissement
constitué d’un serveur “terminal server” et de
15 postes opérateurs. Considérons deux cas.
Dans le premier, le serveur a une seule alimentation, un taux de défaillance λ de
3,76.10-5 (ce qui correspond à un MTTF de
26.604 heures), et un temps de réparation
MTTR de 13 heures. Dans ces conditions, la
disponibilité est de 99,951 % et l’indisponibilité est de 0,049 % (4,3 heures). Dans
le deuxième cas, l’alimentation du serveur
est doublée, ce qui permet d’avoir un MTTF
de 33 795 heures, une disponibilité de
99,96152 % et une indisponibilité de
0,03848 %, soit 3,4 heures seulement.
Absence de service rendu aux utilisateurs.
Chaque arrêt du serveur entraîne l’arrêt de
l’atelier pour raisons de sécurité, avec un
manque à gagner de 10000 € de l’heure.
Pour une indisponibilité du serveur de
0,049 %, soit 4,3 heures sur un an, le coût
total annuel s’élève à 43000 €.
En doublant l’alimentation, le taux d’indisponibilité passe à 3,4 heures. On réalise un
gain annuel de plus de 9000 €, et investir
de l’ordre de 500 € supplémentaires pour
s’équiper d’un serveur à alimentation redondante est amorti en un peu moins de
3 semaines (ROI = 20 jours)!
Perte de données. Celles-ci sont dues à une
défaillance du disque dur. Pour un système
comportant 8 disques durs ayant chacun un
taux de défaillance λ de 2.10-6 par heure, il y
a environ 1 “chance” sur 7 que cette perte de
données se produise une fois par an. En effet,
le MTTF du groupe de disques durs est de
50
1/(8.2.10-6) = 62500 heures, ce qui correspond à 7,13 ans.
Dans notre exemple, le serveur de données
est sauvegardé une fois par jour. Le retard
moyen d’une sauvegarde est donc de
12 heures. Si la perte des données représente 30000 € de l’heure, ce sont 360000 €
qui seront perdus à chaque perte de disque
dur. Puisque hélas, pour revenir à notre
exemple précédent, nous subirons en
moyenne cet incident une fois toutes les
7,13 années, il nous en coûtera plus de
50000 € par an.
En doublant l’alimentation, le coût de la perte des données du disque dur reste inchangé, puisque la redondance d’alimentation ne
réduira pas a priori le risque de défaillance de
ce dernier.
Echec de la mission. Un serveur assure la
traçabilité des opérations de production d’un
produit pharmaceutique. Ce produit sera mis
à l’égout si la trace est interrompue en cours
de mission. Si la durée de mission est de
72 heures, et que son interruption coûte
200000 € (par exemple 100 kg de produit
à 2000 €/kg), nous pouvons calculer qu’à
partir du taux de défaillances λ=3,76.10-5, la
fiabilité de mission serait de R=0,9973, soit
une probabilité de défaillance pendant la mission de 1-0,9973=0,0027. La perte moyenne par mission sera de 540 €, et si 100 missions sont effectuées chaque année, nous
perdrons près de 54000 € par an.
En doublant l’alimentation, ce sont encore
plus de 11000 € par an qui seront écono-
misés, soit un investissement amorti en une
quinzaine de jours!
Un gain important
pour un coût négligeable
En bref, le surcoût d’un serveur à alimentation redondante semble négligeable en rapport au retour généré, et nous n’hésiterons
pas une seconde. Cependant, malgré ce “tour
de passe-passe” qui nous a permis de parcourir une petite partie du chemin, nous
perdons encore plusieurs dizaines de milliers d’euros par an à cause des défaillances
restantes. Ces dernières ne se laisseront
dompter qu’aux prix de solutions plus complexes et plus coûteuses.
Daniel Lelièvre
Factory Systèmes*
[email protected]
*Factory Systèmes
22, rue Vladimir Jankelevitch
Emerainville
77437 Marne la Vallée Cedex 2
Tél.: 01 64 61 68 68 - Fax: 01 64 61 67 34
Le dernier article de notre série, qui sera publié dans notre
prochain numéro, sera plus particulièrement consacré aux
applications concrètes, et plus particulièrement aux serveurs à haute disponibilité que l’on peut trouver sur le
marché.
1Cette approche est évidemment fausse, puisqu’un voyant
qui refuse de s’allumer n’a pas forcément de conséquence
immédiate sur le comportement du système. Mais l’erreur
de calcul ira dans le sens du pessimisme, qui est la qualité
première du fiabiliste.
2La disponibilité d’un système est l’aptitude à délivrer un
service, exprimée en pourcentage du temps total
MESURES 762 - FEVRIER 2004
Solutions
INFORMATIQUE INDUSTRIELLE
Fiabiliser, ça
peut rapporter
gros! (3)
▼
Après la théorie, place aux travaux pratiques ! Nous terminons ici la série de trois
articles consacrée à la fiabilité des serveurs informatiques. Cet article s’inscrit dans
la continuité du précédent (voir notre numéro de février) où avait été évoqué l’intérêt de doubler certaines parties fragiles des systèmes. Ici, on aborde la redondance massive de l’ensemble des éléments du système, son apport en terme de
disponibilité et les économies potentielles réalisées.
T
out le monde en convient, l’ajout
de redondances à un système
contribue à améliorer sa fiabilité. Mais comme il faut toujours
mettre en balance ce que coûtent une indisponibilité du système d’un côté et ce que
coûte l’amélioration de la fiabilité de l’autre,
il est essentiel d’utiliser la redondance à bon
escient, “de ne pas faire de la redondance
pour de la redondance”. Pour fixer les axes de
travail, une approche simple est de calculer le
gain théorique qui serait réalisé si l’on ne
subissait “jamais” la défaillance de tel ou tel
composant. Il suffit de “neutraliser” le composant choisi en lui
conférant un λ (taux
L’essentiel
de défaillances) de 0,
La productivité, la qualité
ou en le supprimant
et la sécurité des installapurement et simpletions industrielles peuvent
ment de l’architecture.
être améliorées en limitant
On pourra ainsi déterles temps d’arrêt des ordinateurs
miner si la fiabilisation
Il existe de nombreuses
dudit composant prétechniques permettant
sente un réel intérêt,
d’améliorer la disponibilité
avant de se lancer dans
Toutes ont un coût, qui
une analyse détaillée.
doit être mis en regard des
enjeux recherchés
Les constructeurs,
Les architectures à redondepuis des années,
dance massive permettent
connaissent
ces
de très fortement augmen“maillons faibles” et
ter la disponibilité
se sont attachés à pro-
60
poser des options de fiabilisation. Alimentations doublées, disques miroirs ou
Raid X et réseaux redondants sont autant
de redondances partielles répondant aux
besoins spécifiques des applications.
Cependant, ces offres restent très éloignées
de l’architecture idéale qui nous permettrait de “dormir sur nos deux oreilles”
quelle que soit la défaillance rencontrée.
Concevoir un tel système, c’est se heurter
à de nombreux obstacles liés à la nécessité de supporter les systèmes d’exploitation commerciaux et les applications qu’ils
accueillent, ainsi que les standards matériels les plus répandus. Enfin, comment
permettre, après défaillance et réparation,
le redémarrage “à chaud” d’un composant neuf, qui ne connaît ni sa mission, ni
l’état d’avancement de celle-ci ?
Ces contraintes, d’une grande complexité,
expliquent le faible nombre de solutions standards disponibles sur le marché. Les sociétés Stratus et Marathon Technologies (représentées
par Factory Systèmes) ont toutes deux développé des solutions de redondance massive destinées aux applications où toute défaillance
du serveur doit être évitée (ou plutôt tolérée). Leur architecture matérielle est très
comparable. Les deux constructeurs ont
recours à la redondance massive d’ordre 2,
ou “DMR” (Dual Modular Redundancy) selon
Stratus, et les chiffres annoncés sont très voisins en matière de disponibilité
(99,999 %), ce que nous tenterons de vérifier par le calcul.
Leur différence réside principalement dans le
fait que MarathonTechnologies propose d’éloigner
les sous-systèmes, alors que Stratus les confine
dans une même enceinte. Enfin, Stratus propose une version “TMR” (Triple Modular
Redundancy), redondance massive d’ordre 2
avec redondance partielle d’ordre 3.
Deux modes de redondances
Voyons de plus près les serveurs FTServer de
Stratus. Ceux-ci sont découpés en deux soussystèmes distincts : d’une part, le sous-système d’entrées-sorties, qui gère le bus PCI et les
unités de disque, et d’autre part le sous-système de traitement, qui intègre les fonctions
CPU et mémoire. En mode DMR, conçu pour
tolérer n’importe quelle faute unique sur
chaque sous-système, la redondance est
d’ordre 2 pour chaque sous-système.En mode
TMR, conçu pour tolérer n’importe quelle
double faute du sous-système de traitement,
la redondance est d’ordre 2 pour le sous-système d’entrées-sorties, et d’ordre 3 pour le
sous-système CPU et mémoire. Un système
FTServer est donc constitué au total de 4 ou
5 sous-systèmes, suivant que l’on a affaire à
l’architecture DMR ou à l’architecture TMR.
MESURES 764 - AVRIL 2004
Solutions
Architectures redondantes
Ce schéma représente le découpage en sous-unités d’un serveur Stratus à architecture TMR.Il est également proposé en mode DMR (dans ce cas,il y a seulement deux CPU au lieu de trois.
Les flux entre les sous-systèmes sont traités
par des composants ASIC spécialisés, qui assurent la détection des fautes (comparaison et
algorithme de détection en mode DMR, vote
en mode TMR). Les CPU de chaque sous-système de traitement sont maintenus en stricte synchronisation (chaque CPU exécute
rigoureusement la même instruction que
son homologue).
Les connexions physiques, assurées par des
câbles ou par un fond de panier passif, sont
redondantes.
Quelle que soit la défaillance, la procédure
de maintenance se résume à échanger “à
chaud” le sous-ensemble en cause. Le système se charge automatiquement de la reconfiguration du sous-ensemble neuf. Ainsi, le
MTTR (temps de réparation) est réduit, ainsi que le risque d’erreur humaine.
La défaillance d’un quelconque composant
d’un des sous-systèmes provoque la défaillance du sous-système. Ce sous-système est
réparable. Pour étudier le comportement de
l’ensemble du système redondant, en
incluant les mises hors service puis les réparations des différents sous-systèmes, on utilise les graphes de Markov, qui font intervenir les taux de défaillance (λ), les taux de
couverture (C) et le taux de réparation (µ)
des différents éléments qui composent
chaque sous-système.
Nous avons donc décomposé notre ftServer
en 4 sous-systèmes, 2 CPU et 2 ES, chacun
dotés de leur propre taux de défaillances,
taux de réparation et taux de couverture. Les
CPU intègrent les CPU eux-mêmes, la
mémoire, le chipset, l’ASIC SNP, et les composants de liaison dédiés. Chaque ES intègre
le bus PCI, la carte réseau, les unités de
disque, l’ASIC SSP, et les composants de liaison dédiés. Le fond de panier est caractérisé
par son taux de défaillance (λFP), et on postule que sa double défaillance (λFP2) est
nécessaire pour provoquer la défaillance du
système.
Des résultats tangibles
Calculs pour un système DMR. Le système
DMR pouvant survivre en présence de la défaillance d’une
CPU et d’un ES, on aboutit à
Comparaison des architectures
un graphe de Markov à
5 états : “OK”, “1 ES HS”, “1
Type de serveur
Durée d’indisponibilité/an
CPU HS, 1 ES et 1 CPU HS”,
Serveur standard
4,3 heures
“Système HS”.
Serveur avec alimentation doublée 3, 4 heures
Pour calculer le MTTF du sysServeur DMR
tème, il suffit d’appliquer les
(redondance massive d’ordre 2)
5 minutes
formules qui décrivent les difServeur TMR
férents changements d’états.
(redondance massive d’ordre 3)
3 minutes
Pour permettre des comparaisons avec les exemples décrits
MESURES 764 - AVRIL 2004
dans le deuxième article de notre série, et
apprécier les améliorations apportées par la
redondance, nous avons repris les mêmes
valeurs pour les différents paramètres λ, µ et
Quelques rappels
Dans l’article précédent, nous avions défini un
certain nombre de termes, que nous vous rappelons ici :
MTTF : Temps moyen jusqu’à la défaillance
MTTR : Temps moyen de réparation
MTBF : Temps moyen entre défaillances
λ : Taux de défaillance
µ : Taux de réparation
Disponibilité : aptitude à délivrer le service
Indisponibilité : contraire de la disponibilité
…et quelques formules
λ=
1
MTTF
(formule applicable à des éléments dont le taux
de défaillance est constant, ce qui est le cas des
composants électroniques)
µ=
1
MTTR
MTBF = MTTF + MTTR
Disponibilité =
MTTF
MTTF + MTTR
= 1-
MTTR
MTBF
Indisponibilité = 1 – Disponibilité =
MTTR
MTBF
61
Solutions
Graphe de Markov d’un système DMR
C (taux de couverture). Pour les nouveaux
paramètres apparus dans cet exemple, nous
avons attribué la valeur de 99,5 % à CES et
CCPU (taux de couverture de, respectivement,
le sous-système d’entrées/sorties et le CPU).
Dans les deux cas, la probabilité de non-couverture est principalement celle d’un mauvais diagnostic lorsque les comparaisons
entre les deux sous-systèmes font apparaître
une discordance. Autrement dit, dans une
situation sur 200, le système “se trompe”
de sous-système (entre celui qui est opérationnel et celui qui est en panne) ou encore il ne parvient pas à masquer la faute. Ce
taux de couverture est très dépendant du
savoir-faire du constructeur. Par ailleurs, nous
avons choisi un MTTR de 1 heure pour chacun des sous-systèmes, auquel s’ajoute un
temps d’intervention de 8 heures, soit un
MTTR effectif de 9 heures. Nous avons enfin
choisi un MTTR système de 8 heures, auquel
il faut ajouter un temps d’intervention de
8 heures, ce qui donne un MTTF effectif de
16 heures (on estime qu’en cas de défaillance complète du système, son redémarrage
sera plus long, nécessitant par exemple la
restauration d’applications, de données ou
du système d’exploitation).
Ainsi, en reprenant les valeurs attribuées précédemment aux différents paramètres et en
attribuant des chiffres réalistes aux nouveaux
paramètres apparus dans cet exemple, on
arrive à :
- MTTF = 1 946 392 heures
- A = 99,999178 %
- Q = 0,000822 %, soit moins de 5 minutes
d’indisponibilité par an.
Calculs pour un système TMR. Avec l’architecture TMR, le serveur accueille un troisième sous-système CPU.
Ce dernier va non seulement, permettre de
tolérer une seconde défaillance des sous-sys-
Économies réalisées grâce à la redondance
Perte par indisponibilité du service
Serveur standard
Serveur DMR
Perte de données
Serveur standard
Serveur DMR
Perte par interruption
de la mission
Serveur standard
Serveur DMR
Fréquence Heures perdues
sauvegarde par incident
24 h
12
Coût / heure
Heures perdues / an
Coût annuel
10 000 €
4,3
0,07
Gain
42 815 €
720 €
42 095 €
Coût / heure
Heures perdues / an
Coût annuel
30 000 €
1,7
0,054
Gain
50 458 €
1 620 €
48 837 €
Durée
mission
Coût par lot
Nombre de lots
fabriqués par an
Coût par lot
Coût annuel
72 h
200 000 €
100
540 €
7,4 €
Gain
53 981 €
740 €
53 981 €
Investissement
ROI
30 000 €
8,6 mois
Investissement
ROI
30 000 €
7,4 mois
Investissement
ROI
30 000 €
6,8 mois
Sur la base d’un surcoût (variable suivant les configurations) de 30 000 € par rapport à un serveur de base,nous observons des retours sur investissement (ROI,Return on investment) au bout de 6 mois seulement.Au-delà,ce sont plusieurs dizaines de milliers d’euros qui seront gagnés chaque année.
A l’heure où la majeure partie des investissements est consacrée à l’amélioration des ressources existantes,un tel retour sur investissement reste exceptionnel et mérite qu’on s’y intéresse.
62
MESURES 764 - AVRIL 2004
Solutions
Graphe de Markov d’un système TMR
On estimera que le taux de couverture du
sous-système CPU en mode TMR est 5 fois
supérieur à celui du mode DMR (celui du
sous-système ES reste inchangé).
Sur cette base, on obtient :
MTTF = 2 832 865 heures
A = 99,999435 %
Q = 0,000565 %, soit moins de 3 minutes
par an.
Note importante. Nous l’avons déjà précisé
mais nous devons insister sur ce point : les
données de base (MTTF composants) utilisées dans cette étude sont identiques à celles
de serveurs “standards”, afin de permettre
la comparaison des architectures. Ce faisant,
les comparaisons sont plutôt défavorables
aux constructeurs de serveurs redondants.
Ceux-ci utilisent en effet des composants fiabilisés (donc avec des valeurs de λ
meilleures), et ils proposent donc des MTTF
supérieurs.
Daniel Lelièvre
*Factory Systèmes
tèmes CPU, mais il augmentera considérablement le taux de couverture de ces mêmes
sous-systèmes : lors de la défaillance de l’un
d’entre eux, la détection de faute ne s’effec-
MESURES 764 - AVRIL 2004
tue plus par comparaison suivie d’une stratégie de localisation basée sur des règles, mais
sur un vote binaire des données, où les données erronées sont automatiquement exclues.
22, rue Vladimir Jankelevitch
Emerainville
77437 Marne la Vallée Cedex 2
Tél.: 01 64 61 68 68 - Fax: 01 64 61 67 34
63