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

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)?

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).

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.

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.

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.