Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Disponibilité du système distribué
Les systèmes distribués sont composés à la fois de composants logiciels et de composants matériels. Certains composants logiciels peuvent eux-mêmes être un autre système distribué. La disponibilité des composants matériels et logiciels sous-jacents influe sur la disponibilité de votre charge de travail qui en résulte.
Le calcul de la disponibilité à l'aide du MTBF et du MTTR trouve ses racines dans les systèmes matériels. Cependant, les systèmes distribués échouent pour des raisons très différentes de celles d'un élément matériel. Lorsqu'un fabricant peut calculer régulièrement le délai moyen avant qu'un composant matériel ne s'use, les mêmes tests ne peuvent pas être appliqués aux composants logiciels d'un système distribué. Le matériel suit généralement la courbe « baignoire » du taux de défaillance, tandis que le logiciel suit une courbe échelonnée produite par des défauts supplémentaires introduits à chaque nouvelle version (voir Fiabilité des logiciels
Taux de défaillance du matériel et des logiciels
En outre, les logiciels des systèmes distribués évoluent généralement à un rythme exponentiellement supérieur à celui du matériel. Par exemple, un disque dur magnétique standard peut avoir un taux de défaillance annualisé (AFR) moyen de 0,93 %, ce qui, dans la pratique, peut se traduire par une durée de vie d'au moins 3 à 5 ans avant qu'il n'atteigne la période d'usure, voire plus longtemps (voir Backblaze Hard
Le matériel est également soumis au concept d'obsolescence planifiée, c'est-à-dire qu'il a une durée de vie intrinsèque et qu'il devra être remplacé après un certain temps. (Voir The Great Lightbulb Conspiracy
Tout cela signifie que les mêmes modèles de test et de prédiction utilisés pour le matériel pour générer les numéros MTBF et MTTR ne s'appliquent pas aux logiciels. Des centaines de tentatives ont été faites pour créer des modèles pour résoudre ce problème depuis les années 1970, mais elles se répartissent généralement en deux catégories : la modélisation prédictive et la modélisation d'estimation. (Voir la liste des modèles de fiabilité des logiciels
Ainsi, le calcul d'un MTBF et d'un MTTR prospectifs pour les systèmes distribués, et donc d'une disponibilité prospective, sera toujours dérivé d'un certain type de prédiction ou de prévision. Ils peuvent être générés par le biais d'une modélisation prédictive, d'une simulation stochastique, d'une analyse historique ou de tests rigoureux, mais ces calculs ne constituent pas une garantie de disponibilité ou d'indisponibilité.
Les raisons pour lesquelles un système distribué a échoué dans le passé peuvent ne jamais se reproduire. Les raisons pour lesquelles il échouera à l'avenir seront probablement différentes et peut-être inconnaissables. Les mécanismes de restauration requis peuvent également être différents de ceux utilisés dans le passé pour les défaillances futures et prendre des durées très différentes.
De plus, le MTBF et le MTTR sont des moyennes. Il y aura un certain écart entre la valeur moyenne et les valeurs réelles observées (l'écart type, σ, mesure cette variation). Ainsi, les charges de travail peuvent s'écouler plus ou moins longtemps entre les défaillances et les temps de restauration dans le cadre d'une utilisation réelle en production.
Cela dit, la disponibilité des composants logiciels qui constituent un système distribué est toujours importante. Les logiciels peuvent échouer pour de nombreuses raisons (abordées plus en détail dans la section suivante) et ont un impact sur la disponibilité de la charge de travail. Ainsi, pour les systèmes distribués à haute disponibilité, il convient d'accorder autant d'importance au calcul, à la mesure et à l'amélioration de la disponibilité des composants logiciels qu'aux sous-systèmes matériels et logiciels externes.
Règle 2
La disponibilité du logiciel dans votre charge de travail est un facteur important de la disponibilité globale de votre charge de travail et doit bénéficier de la même attention que les autres composants.
Il est important de noter que même si le MTBF et le MTTR sont difficiles à prévoir pour les systèmes distribués, ils fournissent tout de même des informations clés sur la manière d'améliorer la disponibilité. La réduction de la fréquence des défaillances (MTBF plus élevé) et la diminution du temps de rétablissement après une défaillance (MTTR plus faible) permettront toutes deux d'améliorer la disponibilité empirique.
Types de défaillances dans les systèmes distribués
Il existe généralement deux catégories de bogues dans les systèmes distribués qui affectent la disponibilité, appelées affectueusement Bohrbug et Heisenbug (voir « A Conversation with Bruce Lindsay », ACM Queue vol. 2, n° 8 — novembre 2004).
Un bohrbug est un problème logiciel fonctionnel récurrent. Avec la même entrée, le bogue produira systématiquement la même sortie incorrecte (comme le modèle atomique déterministe de Bohr, qui est solide et facile à détecter). Ces types de bogues sont rares au moment où une charge de travail passe en production.
Un Heisenbug est un bogue transitoire, c'est-à-dire qu'il ne se produit que dans des conditions spécifiques et peu communes. Ces conditions sont généralement liées à des éléments tels que le matériel (par exemple, une défaillance passagère du périphérique ou des spécificités de l'implémentation matérielle, comme la taille du registre), les optimisations du compilateur et l'implémentation du langage, les conditions limites (par exemple, un manque de stockage temporaire) ou les conditions de course (par exemple, ne pas utiliser de sémaphore pour les opérations multithread).
Les Heisenbugs constituent la majorité des bogues en production et sont difficiles à détecter car ils sont insaisissables et semblent changer de comportement ou disparaître lorsque vous essayez de les observer ou de les corriger. Toutefois, si vous redémarrez le programme, l'opération échouée sera probablement couronnée de succès car l'environnement d'exploitation est légèrement différent, éliminant ainsi les conditions à l'origine du Heisenbug.
Ainsi, la plupart des défaillances de production sont transitoires et il est peu probable qu'elle échoue à nouveau lorsque l'opération est tentée à nouveau. Pour être résilients, les systèmes distribués doivent être tolérants aux défaillances face aux Heisenbugs. Nous verrons comment y parvenir dans la section Augmenter le MTBF des systèmes distribués.
