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

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

J'ai fait le calcul comme suit:

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

Cela signifie que le système n'a que moins d'une seconde de temps d'arrêt au cours de la période de 20 ans. Je n'essaie pas de contester la validité de cela, je suis simplement curieux de savoir comment nous pouvons arrêter un système (volontairement ou par accident) pendant seulement 0,631 seconde. Quelqu'un qui est familier avec un grand système logiciel pourrait-il nous expliquer cela? Je vous remercie.

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

Le chiffre de fiabilité n'était pas censé mesurer le temps total pendant lequel une partie du AXD301(projet en question) a été arrêté pendant plus de 20 ans. Cela représente la durée totale de ces 20 années pendant laquelle le service fourni par le AXD301système a été hors ligne. Différence subtile. Comme le dit Joe Armstrong ici :

L'AXD301 a atteint une fiabilité NINE neuf (oui, vous avez bien lu, 99,9999999%). Mettons cela en contexte: 5 neuf sont considérés comme bons (5,2 minutes de temps d'arrêt / an). 7 neuf presque irréalisable ... mais nous en avons fait 9.

Pourquoi est-ce? Aucun état partagé, plus un modèle de récupération d'erreur sophistiqué.

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

L'un des projets étudiés dans ce chapitre est l'Ericsson AXD301, un commutateur ATM haute performance hautement fiable .

Ainsi, tant que le réseau dont faisait partie le commutateur fonctionnait sans temps d'arrêt, l'auteur peut déclarer «fiabilité neuf neuf» pour AXD301(ce qu'il n'a jamais dit, évitant les détails). Cela ne signifie pas nécessairement qu'Erlang est la seule cause d'une fiabilité aussi élevée.

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 ce n'est pas réellement lié au chiffre de fiabilité neuf-neuf, qui est potentiellement issu d'une étude beaucoup plus courte (comme d'autres l'ont mentionné).

Alors que les autres ont abordé le cas spécifique dont vous parlez, votre question semble être basée sur un malentendu. La façon dont vous avez posé la question me fait croire que vous pensez qu'il existe un processus manuel pour remettre le système en marche après qu'il se bloque ou qu'il soit mis hors service pour maintenance.

Erlang a plusieurs fonctionnalités qui suppriment le temps de travail humain comme source de temps d'arrêt:

1. Rechargement de 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 le swap automatiquement sans apparemment rien arrêter. Il y a sans aucun doute un temps minime pendant lequel ce transfert se produit, mais il se produit automatiquement dans le temps de l'ordinateur, plutôt que manuellement dans le temps humain. Cela permet d'effectuer des mises à niveau avec pratiquement aucun temps d'arrêt. (Vous pourriez avoir un temps d'arrêt si le module de remplacement a un bogue qui plante le système, mais c'est pourquoi vous testez avant de déployer en production.)

2. Superviseurs . La bibliothèque OTP d'Erlang a un cadre de supervision intégré qui vous permet de définir comment le système doit réagir en cas de panne d'un module. L'action standard ici est de redémarrer le module défaillant. En supposant que le module redémarré ne plante pas à nouveau immédiatement, le temps d'arrêt total facturé sur votre système peut être une question de millisecondes. Un système solide qui ne plante pratiquement jamais pourrait en effet accumuler seulement une fraction de seconde du temps d'arrêt total au cours des années de fonctionnement.

3. Processus . Celles-ci correspondent à peu près aux threads dans d'autres langues, sauf qu'elles ne partagent pas l'état sauf via des magasins de données persistants. En dehors de cela, la communication se fait par passage de messages. Étant donné que les processus Erlang sont très peu coûteux (beaucoup moins chers que les threads OS), cela encourage une conception faiblement couplée, de sorte que si un processus meurt, seule une infime partie du système subit des temps d'arrêt. En règle générale, le superviseur redémarre ce processus, avec peu ou pas d'impact sur le reste du système.

4. Message asynchrone passant . 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 d'envoi de message n'a pas à attendre que le destinataire traite le message, et il n'a pas à coordonner la propriété des données envoyées. La nature fonctionnelle asynchrone du système de transmission 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 les temps d'arrêt dans une partie d'un système peuvent avoir sur d'autres parties.

5. Clustering . Cela 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 à se soucier que le récepteur soit sur une machine séparée. Cela fournit un mécanisme simple pour répartir une charge de travail entre de nombreuses machines, chacune pouvant être arrêtée séparément sans nuire à la disponibilité globale du système.

Le chiffre de disponibilité de 99,9999999% est une statistique souvent citée mais fondamentalement trompeuse. Mats Cronqvist, l'un des membres de l'équipe AXD-301, a fait 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, il a été réclamé par British Telecom pour une période d'essai (je crois de janvier à septembre 2002) de "5 nœuds-années" en utilisant l'AXD-301. À la fin de l'essai, 14 nœuds transportaient du trafic en direct.

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

Il faut dire que je suis un fervent partisan et développeur d'Erlang, qui pense que l'utilisation experte d'Erlang peut en effet conduire à des systèmes très hautement disponibles, mais veut juste 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.

Ma compréhension de ces statistiques est qu'elles sont calculées sur TOUS les systèmes AXD301 en production. Nous pouvons nous attendre à ce que lorsqu'un AXD301 a un problème grave, il soit arrêté pendant plus de 0,631 seconde. Durant cette période, d'autres AXD301 prendront le relais pour maintenir le réseau opérationnel.

Cependant, lorsque vous additionnez le nombre total d'heures de tous les AXD301 en cours d'exécution, faites le rapport pour celui qui échoue AXD301, vous trouvez 99,999999%

Voilà comment je comprends ce chiffre.

J'espère que cette aide.