Confiabilidad del 99,9999999% (nueve nueves) de Erlang


98

Se informó que Erlang se ha utilizado en sistemas de producción durante más de 20 años con un porcentaje de tiempo de actividad del 99,9999999%.

Hice las matemáticas de la siguiente manera:

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

Eso significa que el sistema solo tiene menos de un segundo de tiempo de inactividad durante el período de 20 años. No estoy tratando de cuestionar la validez de esto, solo tengo curiosidad por saber cómo podemos apagar un sistema (a propósito o por accidente) por solo 0.631 segundos. ¿Alguien que esté familiarizado con un gran sistema de software podría explicarnos esto? Gracias.


¿Alguien sabe cómo calcular el tiempo de inactividad de un servicio en un grupo de unidades de procesamiento (o máquinas)?


28
Tal vez se utiliza en waayyyyyy más de un ordenador - algunos países tienen una tasa de natalidad de 1,2 hijos ...
weltraumpirat

3
@weltraumpirat Esto tiene sentido, debido a la naturaleza distribuida de Erlang, debe usarse en muchas computadoras.
Ning

12
Sí. Es el tiempo de actividad del servicio, no las computadoras que lo ejecutan.
RCE

Respuestas:


85

Se suponía que la cifra de confiabilidad no debía medir el tiempo total que alguna parte de AXD301(proyecto en cuestión) estuvo cerrada durante más de 20 años. Representa el tiempo total durante esos 20 años que el servicio proporcionado por el AXD301sistema estuvo fuera de línea. Diferencia sutil. Como dice Joe Armstrong aquí :

El AXD301 ha alcanzado una fiabilidad de NUEVE nueves (sí, lo leíste bien, 99,9999999%). Pongamos esto en contexto: 5 nueves se considera bueno (5,2 minutos de tiempo de inactividad / año). 7 nueves casi inalcanzables ... pero lo hicimos 9.

¿Por qué es esto? Sin estado compartido, además de un sofisticado modelo de recuperación de errores.

Si profundiza un poco más, en la tesis doctoral escrita por Joe, el autor original de Erlang (que incluye un estudio de caso de AXD301), lee:

Uno de los proyectos estudiados en este capítulo es el Ericsson AXD301, un conmutador ATM de alto rendimiento y gran fiabilidad .

Por lo tanto, siempre que la red de la que formaba parte el conmutador funcionara sin tiempo de inactividad, el autor puede declarar "confiabilidad de nueve nueves" AXD301(que fue todo lo que dijo, evitando detalles). No significa necesariamente que Erlang sea la única causa de una fiabilidad tan alta.

EDITAR: De hecho, "20 años" en sí parece una mala interpretación. Joe menciona una cifra de 20 años en el mismo artículo, pero en realidad no está relacionada con la cifra de fiabilidad de nueve nueves, que potencialmente surgió de un estudio mucho más corto (como han mencionado otros).


13
"Sí. Es el tiempo de actividad del servicio, no las computadoras que lo ejecutan". - Dice RCE
Luke Stanley

¡Es como si estuviera de regreso en la escuela en GT MSCS 1993! Lo lograste.
Mike Polen

2
Como expliqué en mi respuesta, esta cifra no se basó en 20 años de funcionamiento del AXD301. Se basó en 14 nodos durante un período de 8 meses en una única prueba de British Telecom. Esto apenas es representativo de las características operativas de toda la línea AXD301 durante 20 años (que estoy seguro de que siguen siendo estelares, solo que no nueve nueves).
Edwin Fine

56

Mientras que los otros han abordado el caso específico sobre el que está preguntando, su pregunta parece estar basada en un malentendido. La forma en que ha hecho la pregunta me hace creer que está pensando que hay un proceso manual para hacer que el sistema vuelva a funcionar después de que se bloquea o se desconecta para mantenimiento.

Erlang tiene varias características que eliminan el tiempo de trabajo humano como fuente de tiempo de inactividad:

  1. Recarga de código caliente . En un sistema Erlang, es fácil compilar y cargar un módulo de reemplazo para uno existente. El emulador BEAM realiza el intercambio automáticamente sin aparentemente detener nada. Sin duda, hay una pequeña cantidad de tiempo durante el cual ocurre esta transferencia, pero ocurre automáticamente en tiempo de computadora, en lugar de hacerlo manualmente en tiempo humano. Esto hace posible realizar actualizaciones prácticamente sin tiempo de inactividad. (Podría tener tiempo de inactividad si el módulo de reemplazo tiene un error que bloquea el sistema, pero es por eso que lo prueba antes de implementarlo en producción).

  2. Supervisores . La biblioteca OTP de Erlang tiene un marco de supervisión integrado que le permite definir cómo debe reaccionar el sistema si un módulo falla. La acción estándar aquí es reiniciar el módulo fallido. Suponiendo que el módulo reiniciado no vuelva a bloquearse inmediatamente, el tiempo de inactividad total cargado contra su sistema podría ser una cuestión de milisegundos. Un sistema sólido que casi nunca falla puede acumular solo una fracción de segundo del tiempo de inactividad total en el transcurso de años de tiempo de ejecución.

  3. Procesos . Estos corresponden aproximadamente a subprocesos en otros idiomas, excepto que no comparten el estado excepto a través de almacenes de datos persistentes. Aparte de eso, la comunicación ocurre a través del paso de mensajes. Debido a que los procesos de Erlang son muy económicos (mucho más baratos que los subprocesos del sistema operativo), esto fomenta un diseño poco acoplado, de modo que si un proceso muere, solo una pequeña parte del sistema experimenta tiempo de inactividad. Normalmente, el supervisor reinicia ese proceso, con poco o ningún impacto en el resto del sistema.

  4. Paso de mensajes asincrónico . Cuando un proceso quiere decirle algo a otro, hay un operador de primera clase en el lenguaje Erlang que le permite hacerlo. El proceso de envío de mensajes no tiene que esperar a que el receptor procese el mensaje y no tiene que coordinar la propiedad de los datos enviados. La naturaleza funcional asincrónica del sistema de paso de mensajes de Erlang se encarga de todo eso. Esto ayuda a mantener altos tiempos de actividad porque reduce el efecto que el tiempo de inactividad en una parte de un sistema puede tener en otras partes.

  5. Agrupación . Esto se desprende del punto anterior: el mecanismo de paso de mensajes de Erlang funciona de forma transparente entre máquinas en una red, por lo que un proceso de envío ni siquiera tiene que preocuparse de que el receptor esté en una máquina separada. Esto proporciona un mecanismo sencillo para dividir una carga de trabajo entre muchas máquinas, cada una de las cuales puede desactivarse por separado sin dañar el tiempo de actividad general del sistema.


14
También es importante tener en cuenta cómo se cuenta el tiempo de inactividad. No importa cuántas veces intercambie módulos de código, reinicie módulos fallidos, etc., siempre que el proceso de cambio del cajero automático no se detenga. Como youtube, la descarga puede pausarse por segundos, pero mientras tenga suficiente búfer, el video aún se reproduce :)
NPSF3000

Todo lo que ha escrito sobre Erlang es correcto; el malentendido es que toda la línea AXD301 tiene una disponibilidad de nueve nueves, que abordo en mi respuesta.
Edwin Fine

33

La cifra de disponibilidad del 99,9999999% es una estadística que se cita a menudo pero que es fundamentalmente engañosa. Mats Cronqvist, uno de los miembros del equipo AXD-301, dio una presentación (video) (a la que asistí) en la conferencia de Erlang Factory 2010 en San Francisco, discutiendo esta estadística precisa de disponibilidad. Según él, British Telecom lo reclamó por un período de prueba (creo que de enero a septiembre de 2002) de "5 años-nodo" utilizando el AXD-301. Había 14 nodos que transportaban tráfico en vivo al final de la prueba.

Cronqvist declaró específicamente que esto no es representativo de toda la historia de AXD-301, o de Erlang en general, y que no estaba contento de que Joe Armstrong siguiera citando esto, lo que generó expectativas exageradas sobre la confiabilidad de Erlang. Otros han escrito que cinco nueves es una cifra más realista.

Cabe señalar que soy un ferviente partidario y desarrollador de Erlang, que cree que el uso experto de Erlang puede conducir a sistemas de alta disponibilidad, pero solo quiere reducir la exageración. Por supuesto, asumo que la representación de Cronqvist de los hechos es precisa y no tengo ninguna razón para creer lo contrario.


7

Mi comprensión de esas estadísticas es que se calcula en TODOS los sistemas AXD301 en producción. Podemos esperar que cuando un AXD301 tenga un problema grave, estará inactivo durante más de 0,631 segundos. Durante este período, otros AXD301 se harán cargo para mantener la red operativa.

Sin embargo, cuando suma el número total de horas de todos los AXD301 en ejecución, haga la relación para el AXD301 que falla, y encontrará 99,999999%

Así es como entiendo esta figura.

Espero que esto ayude.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.