Fiabilité de 99,9999999% (neuf neuf) d'Erlang

Question

Erlang a été utilisé dans des systèmes de production pendant plus de 20 ans avec un pourcentage de disponibilité de 99,9999999%.

J'ai fait les calculs suivants :

20*365.25*24*60*60*(1 - 0.999999999) == 0.631 s

Cela signifie que le système n'a connu que moins d'une seconde d'indisponibilité sur une période de 20 ans. Je n'essaie pas de contester la validité de ce chiffre, mais je suis curieux de savoir comment nous pouvons arrêter un système (volontairement ou par accident) pendant seulement 0,631 seconde. Est-ce que quelqu'un qui est familier avec les grands systèmes logiciels pourrait nous expliquer cela ? Je vous remercie.

---

Quelqu'un sait-il comment calculer le temps d'arrêt d'un service sur une grappe d'unités de traitement (ou de machines) ?

Answer 1

Le chiffre de la fiabilité n'était pas censé mesurer la durée totale d'une partie de l'activité de l'entreprise. AXD301 (projet en question) n'a jamais été fermé pendant plus de 20 ans. Il représente la durée totale pendant laquelle, au cours de ces 20 années, le service fourni par le projet a été interrompu. AXD301 n'a jamais été hors ligne. Une différence subtile. Comme le dit Joe Armstrong aquí :

L'AXD301 a atteint une fiabilité de NEUF neuf (oui, vous avez bien lu, 99,9999999%). Replaçons ce chiffre dans son contexte : Une fiabilité de 5 neuf est considérée comme bonne (5,2 minutes d'indisponibilité par an). 7 neuf, c'est presque irréalisable... mais nous avons fait 9.

Comment cela se fait-il ? Pas d'état partagé et un modèle sophistiqué de récupération des erreurs.

Si vous creusez un peu plus, dans la thèse de doctorat écrite par Joe, l'auteur original d'Erlang (qui comprend une étude de cas de AXD301 ), vous lisez :

L'un des projets étudiés dans ce chapitre est l'AXD301 d'Ericsson, un commutateur ATM très performant et très fiable .

Ainsi, tant que le réseau dont le commutateur faisait partie fonctionnait sans interruption, l'auteur peut affirmer que la fiabilité du commutateur est de neuf neuf. AXD301 (c'est tout ce qu'il a dit, évitant les détails). Cela ne signifie pas nécessairement qu'Erlang est la seule cause d'une telle fiabilité.

EDIT : En fait, "20 ans" lui-même semble être une mauvaise interprétation. Joe mentionne un chiffre de 20 ans dans le même article, mais il n'est pas réellement lié au chiffre de fiabilité de neuf neuf, qui est potentiellement issu d'une étude beaucoup plus courte (comme d'autres l'ont mentionné).

Answer 2

Si les autres ont abordé le cas spécifique que vous évoquez, votre question semble reposer sur un malentendu. La façon dont vous avez posé la question me fait penser que vous pensez qu'il existe un processus manuel pour remettre le système en marche après qu'il se soit arrêté ou qu'il ait été mis hors service pour des raisons de maintenance.

Erlang possède plusieurs caractéristiques qui éliminent le temps de travail humain comme source de temps d'arrêt :

1. Rechargement du code à chaud . Dans un système Erlang, il est facile de compiler et de charger un module de remplacement pour un module existant. L'émulateur BEAM effectue la permutation automatiquement sans apparemment arrêter quoi que ce soit. Il y a sans doute un minuscule laps de temps pendant lequel ce transfert se produit, mais il se produit automatiquement en temps informatique, plutôt que manuellement en temps humain. Cela permet d'effectuer des mises à niveau avec essentiellement zéro temps d'arrêt. (Il peut y avoir des temps d'arrêt si le module de remplacement présente un bogue qui fait planter le système, mais c'est la raison pour laquelle vous testez avant de le déployer en production).

2. Superviseurs . La bibliothèque OTP d'Erlang dispose d'un cadre de supervision intégré qui vous permet de définir la manière dont le système doit réagir si un module tombe en panne. L'action standard ici est de redémarrer le module défaillant. En supposant que le module redémarré ne tombe pas immédiatement en panne, le temps d'arrêt total imputé à votre système peut être de l'ordre de quelques millisecondes. Un système solide qui ne tombe pratiquement jamais en panne peut en effet n'accumuler qu'une fraction de seconde de temps d'arrêt total au cours de plusieurs années d'utilisation.

3. Processus . Ils correspondent à peu près aux threads dans d'autres langages, sauf qu'ils ne partagent pas d'état, si ce n'est par l'intermédiaire de magasins de données persistants. Pour le reste, la communication se fait par passage de messages. Les processus Erlang étant très peu coûteux (bien moins que les threads des systèmes d'exploitation), cela favorise une conception à couplage lâche, de sorte que si un processus meurt, seule une petite partie du système subit un temps d'arrêt. En général, le superviseur redémarre ce processus, avec peu ou pas d'impact sur le reste du système.

4. Transmission asynchrone de messages . Lorsqu'un processus veut dire quelque chose à un autre, il existe un opérateur de première classe dans le langage Erlang qui lui permet de le faire. Le processus qui envoie le message n'a pas besoin d'attendre que le destinataire traite le message, et il n'a pas besoin de coordonner la propriété des données envoyées. La nature fonctionnelle asynchrone du système de passage de messages d'Erlang s'occupe de tout cela. Cela permet de maintenir des temps de fonctionnement élevés, car cela réduit l'effet que l'indisponibilité d'une partie du système peut avoir sur les autres parties.

5. Regroupement . Ceci découle du point précédent : Le mécanisme de transmission de messages d'Erlang fonctionne de manière transparente entre les machines d'un réseau, de sorte qu'un processus d'envoi n'a même pas besoin de se soucier du fait que le destinataire se trouve sur une machine distincte. Cela fournit un mécanisme facile pour diviser une charge de travail entre plusieurs machines, chacune d'entre elles pouvant tomber en panne séparément sans nuire au temps de fonctionnement global du système.

Answer 3

Le chiffre de 99,9999999% de disponibilité est une statistique souvent citée mais fondamentalement trompeuse. Mats Cronqvist, l'un des membres de l'équipe AXD-301, a donné les informations suivantes une présentation (vidéo) (à laquelle j'ai assisté) lors de la conférence Erlang Factory 2010 à San Francisco, discutant de cette statistique précise de disponibilité. Selon lui, elle a été revendiquée par British Telecom pour une période d'essai (je crois de janvier à septembre 2002) de "5 années-nœuds" en utilisant l'AXD-301. À la fin de la période d'essai, 14 nœuds transportaient du trafic en direct.

Cronqvist a spécifiquement déclaré que cela n'était pas représentatif de l'ensemble de l'histoire de l'AXD-301, ou d'Erlang en général, et qu'il n'était pas content que Joe Armstrong ne cesse de le citer, ce qui a conduit à des attentes exagérées quant à la fiabilité d'Erlang. D'autres ont écrit que le chiffre de cinq neuf est plus réaliste.

Il convient de préciser que je suis un fervent partisan et développeur d'Erlang, qui croit que l'utilisation experte d'Erlang peut effectivement conduire à des systèmes très hautement disponibles, mais qui souhaite simplement réduire le battage médiatique. Je suppose bien sûr que la représentation des faits par Cronqvist est exacte, et je n'ai aucune raison de croire le contraire.

Answer 4

Si j'ai bien compris, ces statistiques sont calculées sur TOUS les systèmes AXD301 en production. On peut s'attendre à ce que lorsqu'un AXD301 a un problème grave, il soit indisponible pendant plus de 0,631 seconde. Pendant cette période, d'autres AXD301 prendront le relais pour maintenir le réseau opérationnel.

Cependant, si l'on additionne le nombre total d'heures de tous les AXD301 en fonctionnement, et que l'on fait le ratio pour le AXD301 défaillant, on obtient 99,999999%.

C'est ainsi que je comprends ce chiffre.

J'espère que cela vous aidera.