Erlang 99.9999999%(nueve nueves) confiabilidad
reliability uptime (4)
La cifra de 99.9999999% de disponibilidad es una estadística a menudo citada pero fundamentalmente engañosa. Mats Cronqvist, uno de los miembros del equipo AXD-301, hizo una presentación (video) (a la que asistí) en la conferencia Erlang Factory 2010 en San Francisco, donde se discutió esta estadística de disponibilidad precisa. Según él, British Telecom reclamó durante un período de prueba (creo que de enero a septiembre de 2002) de "5 años-nodos" utilizando el AXD-301. Había 14 nodos que transportaban en vivo al final de la prueba.
Cronqvist declaró específicamente que esto no es representativo de toda la historia de AXD-301, o Erlang en general, y que no estaba contento de que Joe Armstrong continuara citando esto, lo que llevó a expectativas exageradas de la fiabilidad de Erlang. Otros han escrito que cinco nueves es una figura más realista.
Debería decirse que soy un ferviente partidario y desarrollador de Erlang, que cree que el uso experto de Erlang puede conducir a sistemas muy disponibles, pero solo quiere reducir la exageración. Por supuesto, supongo que la representación de Cronqvist de los hechos es precisa y no tiene motivos para creer lo contrario.
Se informó que Erlang se usó en sistemas de producción durante más de 20 años con un porcentaje de tiempo de actividad de 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 desafiar la validez de esto, solo tengo curiosidad sobre cómo podemos cerrar un sistema (a propósito o por accidente) por solo 0,631 segundos. ¿Podría alguien que esté familiarizado con un gran sistema de software 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)?
Mi comprensión de esas estadísticas es que se calcula sobre TODOS los sistemas AXD301 en producción. Podemos esperar que cuando un AXD301 tenga un problema grave, caiga durante más de 0,631 segundos. Durante este pediod, otro AXD301 asumirá el control para mantener la red en funcionamiento.
Sin embargo, cuando suma el número total de horas de todos los AXD301 en ejecución, haga la proporción del AXD301 que falla, encontrará 99.999999%
Así es como entiendo esta figura.
Espero que esto ayude.
Mientras que los otros han abordado el caso específico sobre el que está preguntando, su pregunta parece basarse en una mala interpretación. La forma en que hizo la pregunta me hace creer que está pensando que hay un proceso manual para que el sistema vuelva a funcionar después de que se cuelgue o se retire para realizar tareas de mantenimiento.
Erlang tiene varias características que eliminan el tiempo de trabajo humano como fuente de tiempo de inactividad:
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 de forma automática sin detener aparentemente nada. Sin duda, hay una pequeña cantidad de tiempo durante el cual se produce esta transferencia, pero está sucediendo automáticamente en el tiempo de la computadora, en lugar de manualmente en tiempo humano. Esto hace posible realizar actualizaciones con un tiempo de inactividad esencialmente cero . (Podría tener tiempo de inactividad si el módulo de reemplazo tiene un error que bloquea el sistema, pero es por eso que prueba antes de implementarlo en producción).
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 se bloquee de nuevo inmediatamente, el tiempo de inactividad total cargado en su sistema podría ser 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.
Procesos . Éstos corresponden aproximadamente a hilos 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 envío de mensajes. Debido a que los procesos de Erlang son muy económicos (mucho más económicos que los subprocesos del sistema operativo), esto fomenta un diseño débilmente acoplado, de modo que si un proceso muere, solo una pequeña parte del sistema experimenta un tiempo de inactividad. Típicamente, el supervisor reinicia ese proceso, con poco o ningún impacto en el resto del sistema.
Transmisión asíncrona de mensajes . Cuando un proceso quiere decir algo diferente, hay un operador de primera clase en el lenguaje Erlang que le permite hacer eso. El proceso de envío de mensajes no tiene que esperar que el receptor procese el mensaje, y no tiene que coordinar la propiedad de los datos enviados. La naturaleza funcional asíncrona del sistema de transmisión de mensajes de Erlang se encarga de todo eso. Esto ayuda a mantener altos los tiempos de actividad porque reduce el efecto que el tiempo de inactividad en una parte del sistema puede tener en otras partes.
Agrupación . Esto se sigue 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 importar que el receptor esté en una máquina separada. Esto proporciona un mecanismo fácil para dividir una carga de trabajo entre muchas máquinas, cada una de las cuales puede desconectarse por separado sin dañar el tiempo de actividad general del sistema.
No se suponía que la cifra de confiabilidad midiera el tiempo total que alguna parte de AXD301 (el proyecto en cuestión) se cerró alguna vez durante más de 20 años. Representa el tiempo total durante esos 20 años que el servicio proporcionado por el sistema AXD301 estuvo fuera de línea. Diferencia sutil. Como Joe Armstrong dice here :
El AXD301 ha logrado una NUEVA confiabilidad de nueves (sí, lo has leído 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 hicimos 9.
¿Por qué es esto? Sin estado compartido, más un sofisticado modelo de recuperación de errores.
Si profundizas un poco más, en la tesis de doctorado escrita por Joe, el autor original de Erlang (que incluye un caso de estudio de AXD301 ), lees:
Uno de los proyectos estudiados en este capítulo es el Ericsson AXD301, un conmutador ATM de alto rendimiento y alta fiabilidad .
Entonces, mientras la red de la que formaba parte el conmutador se estuviera ejecutando sin tiempo de inactividad, el autor puede indicar "nueve nueves confiabilidad" para AXD301 (que fue todo lo que dijo, evitando detalles). No necesariamente significa que Erlang es la única causa de tal alta confiabilidad.
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á conectada a la cifra de nueve nueves de confiabilidad, que posiblemente surgió de un estudio mucho más corto (como otros lo han mencionado).