Fiabilité à 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 pendant 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. Est-ce que quelqu'un qui est familier avec un grand logiciel peut nous l'expliquer? Merci.
Quelqu'un sait-il comment 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 d'une partie de AXD301 (projet en question) a été interrompu pendant plus de 20 ans. Il représente le temps total sur ces 20 ans que le service rendu par le AXD301 le système était hors ligne. Différence subtile. Comme le dit Joe Armstrong ici :
L'AXD301 a atteint une fiabilité NINE Nines (oui, vous avez bien lu, 99,9999999%). Mettons cela en contexte: 5 neuf est considéré comme bon (5,2 minutes de temps d'arrêt/an). 7 neuf presque irréalisables ... mais nous l'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 profondément, dans la thèse de doctorat écrite par Joe, l'auteur original d'Erlang (qui comprend une étude de cas de AXD301), Tu lis:
L'un des projets étudiés dans ce chapitre est le Ericsson AXD301, un commutateur ATM hautement fiable et hautement performant .
Ainsi, tant que le réseau dont faisait partie le commutateur fonctionnait sans interruption de service, l'auteur peut indiquer "neuf neuf de fiabilité" pour AXD301 (c'est tout ce qu'il a dit, en é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 il 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 sur lequel vous posez des questions, votre question semble reposer sur une mauvaise compréhension. 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 une panne ou une interruption de maintenance.
Erlang a plusieurs fonctionnalités qui suppriment le temps de travail humain comme source de temps d'arrêt:
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 l'échange automatiquement sans apparemment rien arrêter. Il y a sans doute un tout petit 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. (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.)
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 consiste à redémarrer le module défectueux. En supposant que le module redémarré ne se bloque pas immédiatement à nouveau, le temps d'indisponibilité total facturé à votre système peut être une question de millisecondes. Un système solide qui ne se bloque presque jamais ne pourrait en effet accumuler qu'une fraction de seconde du temps d'arrêt total au cours des années de fonctionnement.
Processus. Ceux-ci correspondent à peu près aux threads dans d'autres langues, sauf qu'ils ne partagent l'état que via des magasins de données persistants. En dehors de cela, la communication se fait via le passage de messages. Parce que les processus Erlang sont très peu coûteux (bien moins chers que les threads du système d'exploitation), cela encourage une conception faiblement couplée, de sorte que si un processus meurt, seule une infime partie du système subit un 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.
passage de message asynchrone. Quand un processus veut dire quelque chose à un autre, il y a un opérateur de première classe dans le langage Erlang qui le permet. 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 disponibilité élevés car il réduit l'effet que les temps d'arrêt d'une partie d'un système peuvent avoir sur d'autres parties.
Clustering. Cela découle du point précédent: le mécanisme de passage 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 se trouve sur une machine distincte. Cela fournit un mécanisme simple pour répartir une charge de travail entre de nombreuses machines, chacune pouvant descendre 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 donné ne présentation(vidéo) (à laquelle j'ai assisté) à la conférence Erlang Factory 2010 à San Francisco, discutant de cette précision statistique de disponibilité. Selon lui, British Telecom l'a revendiqué pour une période d'essai (je crois de janvier à septembre 2002) de "5 années-noeuds" avec 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'était pas représentatif de toute l'histoire de l'AXD-301, ni d'Erlang en général, et qu'il n'était pas content que Joe Armstrong continue de le citer, ce qui conduisait à des attentes exagérées quant à la fiabilité d'Erlang. D'autres ont écrit que cinq neuf est un chiffre plus réaliste.
Il convient de dire que je suis un fervent partisan et développeur d'Erlang, qui estime que l'utilisation experte d'Erlang peut en effet conduire à des systèmes très hautement disponibles, mais 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.
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 rencontre un problème grave, il soit en panne pendant plus de 0,631 seconde. Pendant 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.