Clusters de Computadores Tolerantes a Fallos" Dolores I Rexachs (UAB)

Transcripción

1 SEMINARIO DE SUPERCOMPUTACION: Simplificación del uso de los computadores paralelos, acercando el computador paralelo al usuario Clusters de Computadores Tolerantes a Fallos" Dolores I Rexachs (UAB) 1

2 SEMINARIO DE SUPERCOMPUTACION: Simplificación del uso de los computadores paralelos, acercando el computador paralelo al usuario Clusters de Computadores Tolerantes a Fallos" Dolores I Rexachs (UAB) 2

3 Clusters de Computadores Tolerantes a Fallos Introducción. Conceptos básicos. Fallos y Errores Medidas de fiabilidad Técnicas de Redundancia Protocolos de rollback-recovery basados en Checkpoint y log de mensajes Replicación de Datos Arquitectura distribuida para tolerancia a fallos en grandes Clusters: Redundant Array of Distributed Independent Checkpoints (RADIC): Replicación de Datos para Tolerancia a Fallos en multiclusters: FTDR 3

4 Bibliografía Fault Tolerance in Distributed Systems. P. Jalote. Prentice Hall 1994 Elnozahy, E.N.; Alvisi, L.; Wang, Y. & Johnson, D.B. A Survey of Rollback-recovery Protocols in Messagepassing Systems. ACM Computing Surveys, ACM Press, 2002, 34, Introduction to Parallel Computing (2nd Edition). A. Grama, A. Gupta, G. Karypis, V. Kumar. Pearson Addison Wesley,

5 Cluster: Objetivos de funcionamiento Cluster de alto rendimiento (HP) Enlazar muchos ordenadores para conseguir que funcionen en equipo y obtengan la solución de un problema más rápida trabajando todos juntos en el mismo problema independientemente. Cluster de alta disponibilidad (HAC) Conseguir un sistema de ordenadores mas fiable, compartiendo trabajos y con un funcionamiento redundante, de tal manera que si un ordenador falla otro se encarga de realizar su trabajo. Alta disponibilidad de Procesamiento: Cluster; Nodo; Red de Interconexión Datos: Almacenamiento: RAID 5

6 Introducción Clusters cada vez mas grandes y complejos. Tiempos de cómputo ininterrumpido más largos Componentes trabajando cerca de los límites tecnológicos. Importante: Fiabilidad / Disponibilidad del sistema. La probabilidad de fallos es mucho mayor Es crítico mantenerlos funcionando Es necesario considerar técnicas de Tolerancia a Fallos

7 Cluster de alta disponibilidad (HAC) Intenta mantener en todo momento la prestación de servicio encubriendo los fallos que se pueden producir Requisitos de un HAC Fiabilidad Disponibilidad: Porcentaje del tiempo en el cual el sistema está disponible para el usuario Facilidad de mantenimiento: Facilidad de mantener el sistema en condiciones de operación (reparaciones, actualizaciones, etc) tanto a nivel hardware como software El sistema está disponible el máximo tiempo posible (availability) 7

8 Grandes sistemas Charng-da Lu 8

9 Fiabilidad en grandes sistemas Charng-da Lu 9

10 Necesidad de los sistemas Tolerantes a Fallos Es un problema? Actualmente Aplicaciones Propósito general Históricamente Militares Telemáticas (comunicaciones) Sistemas Fiables Aplicaciones Industriales (Tiempo real) Espaciales y Aeronáuticas Aumenta el número de componentes aumenta probabilidad de fallo Funcionamiento 24 horas x 7 días Tareas críticas que no pueden interrumpir el servicio Computador / Aplicación Paralelo Aumentan el tiempo de ejecución 10

11 Fiabilidad Fiabilidad: (reliability) Medida del éxito con el que el sistema cumple con alguna de las especificaciones obligatorias de su comportamiento Importante: Tiempo durante el cual el sistema puede operar sin pararse (MTTF) Avería (failure) : Cuando el comportamiento de un sistema se desvía del especificado, se dice que se ha producido una avería. Las averías se manifiestan en el comportamiento externo del sistema, pero son el resultado de errores (errors) internos Las causas mecánicas o algorítmicas de los errores se llaman fallos (faults) Fiabilidad 11

12 Retos a la fiabilidad Charng-da Lu 12

13 Tiempo sin servicio anual Tiempo sin servicio anual % de Uptime % de Dowtime Anual Normalizado (segundos) 98,0000% 2,0000% 7,30 días ,0 99,0000% 1,0000% 3,65 días ,0 99,8000% 0,2000% 17 horas, 30 minutos 63000,0 99,9000% 0,1000% 8 horas, 45 minutos 31500,0 99,9900% 0,0100% 52 minutos, 30 segundos 3150,0 99,9990% 0,0010% 5 minutos, 15 segundos 315,0 99,9999% 0,0001% 31,5 segundos 31,5 13

14 Ejemplos: VISA Visa Internacional tuvo 92 minutos sin servicio en los últimos 12 años (99.998%). Es probablemente la instalación comercial más segura del mundo 5 minutos sin servicio significan dejar de procesar 55 millones de dólares en pagos transacciones por segundo (100 trx por segundo) 14

15 Problemas que ocasionan los fallos Crash Omisión Tiempo Bizantino Crash: un componente se para o pierde su estado interno Omisión: Causa que un componente no responda a alguna entrada Tiempo: El componente responde demasiado pronto o demasiado tarde (fallo de rendimiento) Bizantino: Fallos arbitrarios 15

16 Estrategias para obtener fiabilidad Especificación, diseño e implementación 16

17 Limitaciones de la prevención n de fallos Los componentes de hardware fallan, a pesar de las técnicas de prevención La prevención es insuficiente si: La frecuencia o la duración de las reparaciones es inaceptable no se puede detener el sistema para efectuar operaciones de mantenimiento Ejemplo: naves espaciales no tripuladas La alternativa es utilizar técnicas de tolerancia de fallos Informalmente: la capacidad de un sistema a comportarse de una forma bien definida a pesar de que ocurra un fallo 17

18 Diseño o de sistemas tolerantes a fallos Lo ideal es identificar todos los posibles fallos y evaluar las técnicas adecuadas de tolerancia a fallos Fallos que se pueden anticipar, (fallos de disco, sensores para monitorización) Predicción Fallos que no se pueden anticipar Recuperación Objetivo Maximizar la fiabilidad del sistema Minimizar la redundancia. Cuanto mayor es la redundancia mayor complejidad tiene es sistema siendo más propenso a errores Es necesario gestionar adecuadamente la redundancia 18

19 Sistema tolerante a fallos Un Sistema Tolerante a Fallos es aquel que posee la capacidad interna para preservar la ejecución correcta de las tareas a pesar de la ocurrencia de fallos Hardware o Software. 19

20 Fallo / Error / Avería F E A! La garantía de funcionamiento de un sistema disminuye debido a la existencia de: Fallo: defecto o imperfección física en el HW o SW del sistema Error estado interno incorrecto del sistema. Es consecuencia de un fallo Puede ocasionar una avería Avería: El servicio entregado por el sistema no es el especificado. Usuario: el sistema no funciona bien. Debe impedirse que los fallos de todos estos tipos causen averías 20

21 Objetivo El OBJETIVO de la la Tolerancia a Fallos: Evitar la la avería del sistema, incluso en presencia de fallos, es es decir, tratar de conseguir que el el sistema sigua funcionando En sistemas Tolerantes a Fallos, se enmascara la presencia de los fallos usando redundancia (en cualquier nivel). Basado en proteger el trabajo no el computador 21

22 Sistema tolerante a fallos = sistema redundante. La tolerancia de fallos se basa en la redundancia Se utilizan componentes adicionales para detectar los fallos y recuperar el comportamiento correcto. Esto aumenta La complejidad del sistema y puede introducir fallos adicionales El coste del sistema El overhead Puede haber redundancia en cualquier nivel: Redundancia en el hardware: utilización de componentes hardware extra Redundancia temporal: repetición de las operaciones y comparación de los resultados Redundancia en la información: codificación de los datos Redundancia en el software: realización de varias versiones de un mismo programa y del uso de técnicas de consistencia para comprobar que el sistema funciona correctamente. 22

23 Reto: Balancear 23

24 Grados de tolerancia de fallos Tolerancia completa (fail operational) El sistema sigue funcionando, al menos durante un tiempo, sin perder funcionalidad ni prestaciones Degradación aceptable (fail soft, graceful degradation) El sistema sigue funcionando con una pérdida parcial de funcionalidad o prestaciones hasta la reparación del fallo Parada segura (fail safe) El sistema se detiene en un estado que asegura la integridad del entorno hasta que se repare el fallo El grado de tolerancia de fallos necesario depende de la aplicación 24

25 Capas Aplicación (libre de fallos) Middleware (tolerancia a fallos) Cluster (fallos posibles) 25

26 Incorporar Tolerancia a Fallos en clusters Diseñar estrategias para que: Proporcione un sistema fiable con elementos no fiables No degrade prestaciones en ausencia de fallos Mínima sobrecarga (Overhead) Degrade lo mínimo en presencia de fallos: Tolere un número razonablemente alto de fallos Detecte y No deshabilite nodos sanos Bajo Coste: No requiera demasiado hardware extra No introduzca penalizaciones: aumento de la latencia, overhead Sea escalable Sea transparente, M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M Necesitamos Sistemas fiables que permiten la construcción de aplicaciones masivamente paralelas M M M M M M M 26

27 Fiabilidad tolerancia a fallos Requiere Seleccionar el tipo de fallos a proteger Protección: Redundancia Detección Diagnóstico Recuperación: En caso de fallos volver a uno de estos estados y reiniciar la ejecución Reconfiguración: si es necesario Por qué tiene una rueda de repuesto en el coche? Fiabilidad Por qué se van quitando? 27

28 Seleccionar el tipo de fallos a proteger El diseño de la tolerancia a fallos requiere Especificar la clase de fallos que pueden ser tolerados. Especificar los componentes o conceptos que proporcionan protección contra los fallos de todas las clases de fallos toleradas. Cuantos más fallos son tolerados, mejor logramos un sistema con alta disponibilidad (HA) Problema: Coste 28

29 Hardware es sólo s un enlace en la cadena de la disponibilidad (availability) Untested environment No Change Management Overloaded Weak Problem Detection Application Failure 40% Forgot Something Lack of Procedures Backup Errors / Security Operator Error 40% Other 20% but there is more to be considered - Gartner Group,

30 Tipos de fallos: Clasificación n dependiendo de la duración Fallos permanentes: Permanecen hasta que se reparan Ejemplo: roturas de hardware, errores de diseño de software Fallos transitorios: Desaparecen solos al cabo de un tiempo. Se deben a interferencias externas. La forma en que aparecen y la duración es aleatoria Ejemplo: interferencias en comunicaciones Fallos intermitentes: Fallos transitorios que ocurren de vez en cuando, se deben a cierta combinación específica del sistema Ejemplo: calentamiento de un componente de hardware Debe impedirse que los fallos de todos estos tipos causen averías 30

31 Alternativas para incorporar la protección n a Fallos Redundancia de componentes. Hardware extra Redundancia a nivel de información. Realizado desde la aplicación: aplicaciones que incorporan mecanismos de TF. Transparente al usuario (middleware): mecanismos transparentes al usuario, para proteger, detectar fallos, recuperar cuando ocurre un fallo Técnicas: Checkpoint y log de mensajes Replicación de datos 31

32 Mecanismos para Tolerancia a fallos Los nodos en los clusters fallan Cuál es la solución? Re-ejecución de procesos en el nodo fallado? Reparación No siempre es posible o aceptable Re-ejecución de procesos en otros nodos? Redundancia Replicación de datos: Requiere tenerlo en cuenta (SPMD, MW) Checkpointing y migración: Puede ocasionar problema de consistencia Checkpointing y log: Puede ocasionar un gran overhead Dificultades con algunos tipos de aplicaciones Consistencia: Efecto dominó, Aplicaciones que modifican el entorno 32

33 Software view of hardware failures Two classes of faults Fail-stop: a failed processor ceases all operation and does not further corrupt system state Byzantine: arbitrary failures Our focus: Nothing to do with adversaries Fail-Stop Faults 33

34 Posibles configuraciones de Tolerancia a Fallos en Clusters: Activo-Pasivo: Las aplicaciones se ejecutan sobre un conjunto de nodos (activos), mientras que los restantes actúan como backups redundantes de los servicios ofrecidos. Activo-Activo: Todos los nodos actúan como servidores activos de una o más aplicaciones y potencialmente como backups para las aplicaciones que se ejecutan en otros nodos. En cualquier caso, el fallo de un nodo, provoca la migración de las aplicaciones que ejecutaba, a otro nodo del sistema. Si la migración es automática se denomina failover, si es manual switchover. 34

35 Activo-Activo Activo: O 0 O O 2 2 O 3 3 P 1 P 2 P 4 Recursos constantes: degradación Nodo Nodo sobre sobre cargado cargado Posibilidad: Reparación 35

36 Activo-Pasivo Pasivo: P e Prestaciones constantes: Módulos de reserva 36

37 El reto de la recuperación Recovery Point Objective (RPO) How fresh does your data need to be? Recovery Time Objective (RTO) What is your downtime tolerance? Wks Days Hrs Mins Secs Secs Mins Hrs Days Wks Recovery Point Recovery Time File and Print Web Server ebusiness 37

38 Recuperación Rehacer el trabajo debe llevar menos tiempo que hacerlo No es invariable en el tiempo, dependiendo del momento varía Latencia Overhead Coste Se debe equilibrar redundancia y recuperación Time Disaster Recovery Time Objective Business Resumes Ciclo adecuado Ciclo demasiado largo 38

39 Problema: Fallos en clusters La probabilidad de fallos incrementa con el número de nodos (se reduce el MTBF) Aplicaciones con tiempos de ejecución largos (más sensibles al MTBF) Acabar correctamente la aplicación a pesar del fallo de algún nodo Requiere: Detección, Diagnóstico Prevención Recuperación Reconfiguración No siempre es posible o aceptable Re-ejecución de la aplicación Tolerancia a fallos Introduce: Overhead Coste,.. 39

40 Tolerancia a fallos: resumen Capacidad de continuar el procesamiento en presencia de fallos. Alta Disponibilidad: requiere duplicidad y redundancia El fallo debe ser transparente al usuario Lo ideal es identificar todos los posibles fallos y evaluar las técnicas adecuadas de tolerancia a fallos Predicción de fallos (Fault Forecasting): Fallos que se pueden anticipar, por ejemplo, fallos de disco Obtención a priori de la garantía de funcionamiento del sistema. Se realiza una evaluación del comportamiento del sistema ante la ocurrencia del fallo. Fallos que se pueden eliminar: (Fault Removal): Mantenimiento Reducir la presencia (número, seriedad) y el alcance de los fallos mediante: verificación, diagnosis y corrección Tolerancia a Fallos (Fault Tolerant): Fallos que se pueden recuperar Minimizar la redundancia. Mayor redundancia mayor complejidad tiene el sistema más propenso a errores Es necesario gestionar adecuadamente la redundancia Maximizar la fiabilidad del sistema 40

41 Introducción. Conceptos básicos. Organización Definición de fallo, error y avería Garantía de funcionamiento Medidas de fiabilidad Técnicas para aumentar la fiabilidad de un sistema: Técnicas de Redundancia: Checkpoint Modelos, terminología y aspectos generales del rollbackrecovery 41

42 Garantía a de funcionamiento (Dependability) Garantía de Funcionamiento (Confiabilidad) de un sistema informático es la propiedad que permite a sus usuarios depositar una confianza justificada en el servicio que les proporciona. 42

43 Garantía a de funcionamiento (Dependability) Dependiendo de la aplicación, la garantía de funcionamiento pondrá énfasis en un subconjunto de estas características: El sistema funciona sin interrupciones: Fiabilidad (Reliability) El sistema está disponible el máximo tiempo posible (Availability) El sistema no provoca averías catastróficas: Seguridad (Safety)(Proporciona los resultados correctamente) El sistema es fácilmente reparable o utilizable (Serviceability o maintainability) El sistema impide el acceso no autorizado: confidencialidad (confidentiality) El sistema impide la alteración inadecuada de la información: Integridad (integrity) R A S 43

44 Garantía a de funcionamiento: Medidas Confiabilidad (Medidas) Servicio disponible continuamente Disponibilidad de utilización Aptitud para reparaciones y cambios Fiabilidad (R) Disponibilidad (A) Utilizable (S) Fiabilidad -λt = R(t) = e MTBF =1 λ Tiempo Pr oductivo*100 UtilizaciónSistemaTotal(%) = TiempoTotal 44

45 Garantía a de funcionamiento Componentes Garantía de funcionamiento (confiabilidad) Impedimentos (Problemas/daños) Medios (herramientas) Atributos (medidas) Fallo Ejecución Especificación Validación Disponibilidad Fiabilidad Avería Predicción de fallos Tolerancia a fallos Eliminación de fallos Prevención de fallos Seguridad Error circunstancias que causan o son producto los el métodos, modo de y la las herramientas no medidas confiabilidad mediante y soluciones las cuales requeridas se puede estimar para la entregar calidad un de servicio un servicio confiable confiable Mantenimiento 45

46 Medidas de tolerancia a fallos Medida MTTF (mean time to failure) MTTR (mean time to repair) MTBF (mean time between failure) MTBI (mean time between interrupts) Significado Tiempo esperado hasta la ocurrencia de la avería Tiempo medio para reparar el sistema Tiempo medio entre los defectos del sistema Tiempo medio entre las interrupciones del sistema 46

47 Soporte para Disponibilidad Un diseño de alta disponibilidad y robusto requiere Fiabilidad: Durante cuanto tiempo puede operar un sistema sin pararse (MTTF) Disponibilidad: Porcentaje del tiempo que el sistema está disponible para el usuario (MTBF) o (MTBI: Tiempo medio entre interrupciones) Facilidad de Mantenimiento: Indica la facilidad de mantener el sistema en condiciones de operación (reparaciones, actualizaciones, ), tanto a nivel hardware como software (MTTR) MTBI = Tiempototal N º deint errupciones Reliability (Fiabilidad) Availability (Disponibilidad) Serviceability (Reparable) 47

48 Fiabilidad y seguridad Fiabilidad: probabilidad de proporcionar el servicio especificado Para una tasa de fallos de λ averías/hora la media de tiempo entre averías MTTF=1/ λ Si MTTF > 10 9 hablamos de sistemas ultrafiables Seguridad: Los sistemas críticos deben ser fiables. Ciertos proyectos requieren certificación oficial Según Hecht y Hecht (1986), los sistemas software complejos, por cada millón de líneas de código contienen una media de errores El 90% de esos errores pueden ser detectados con sistemas de comprobación. 200 errores de los restantes se detectan durante el primer año. Los 1800 restantes permanecen sin detectar Los requisitos de fiabilidad y seguridad en los STR son mayores que en el resto 48

49 Disponibilidad Disponibilidad = MTBF MTBF + MTTR MTBF = Mean Time Between Failure (Tiempo Medio Entre Fallos) MTTR = Maximun Time To Repair (Máximo Tiempo de Reparación) MTBF MTBF Nodo Sistema Tiempode Pr oducción = N º defallosdeln odo Tiempode Pr oducción = N º defallosdelsistema 49

50 Ciclo de operación-reparaci reparación n de un cluster Disponibilidad = MTTF MTTF + MTTR MTTF (Mean Time To Failure): Tiempo esperado hasta la ocurrencia de la avería MTTR (Mean Time To Repair): Tiempo medio para reparar el sistema 50

51 Aumentar la disponibilidad Opciones Incrementar MTTF incrementar la fiabilidad (difícil) Reducir MTTR Reducir el tiempo de reparación es más habitual en clusters. Se puede conseguir mediante: componentes hardware redundantes aislados programación crítica sujeta a votación (redundancia de ejecución con posterior votación de los resultados) 51

52 Overhead por tolerancia a fallos Overhead que se introduce en cada una de las fases de la tolerancia a fallos: Qué medimos? Protección: Overhead: redundancia, envío, almacenamiento Checkpoint Overhead: es el incremento en el tiempo de ejecución de la aplicación debido a la realización de checkpoint Latencia del Checkpoint: es el tiempo necesario para salvar el checkpoint (depende del tamaño del checkpoint) Detección del error Latencia del error Diagnóstico Latencia del error Recuperación del error: Overhead: Controlador + Reejecución Reconfiguración: consistencia global del sistema overhead controlador 52

53 Relación n temporal en el proceso de creación n de los fallos, errores y averías as Tiempo de inactividad (Fallo dormido): TI = te - tf Tiempo de latencia (Fallo latente): TL = td - te Cobertura es la probabilidad de detectar el fallo (Cobertura en la detección, en la localización, en el aislamiento, en la reconfiguración y en la recuperación) 53

54 Detección n de errores Los fallos no pueden ser observados de forma directa, sino que deben ser deducidos a través de la presencia de errores. Método o error a comprobar función a observar Temporizadores de guardia Heartbeat: Mecanismo de diagnosis de fallo: los nodos del cluster envían un flujo periódico de mensajes de control a los demás. Si el flujo se interrumpe, se diagnostica un fallo en algún nodo o en la red. Puede haber nodos de diagnosis que se dedican a controlar este flujo de mensajes de control. Cuando se detecta el fallo, el nodo que lo detecta debe notificar a los otros nodos que hay un componente con fallo. Seguidamente, el gestor de recursos debe reasignar los servicios de ese componente fallado. 54

55 Latencia Latencia del error: desde el instante en que se produce el fallo hasta que se manifiesta el error. Durante este tiempo de latencia, se dice que el fallo no es efectivo y que el error está latente. Latencia de detección del error Latencia de la producción de la avería. Semanas Días Horas Minutos Segundos Segundos Minutos Horas Días Semanas 55

56 Modelo de Recuperación Se trata de situar el sistema en un estado correcto desde el que pueda seguir funcionando Hay dos estrategias básicas de llevarla a cabo: Recuperación directa (hacia adelante) (FER): Se avanza desde un estado erróneo haciendo correcciones sobre partes del estado Recuperación inversa o Recuperación hacia atrás (BER): Se retrocede a un estado anterior correcto que se ha guardado previamente Los procesos en ejecución periódicamente guardan un estado consistente (checkpoint) en un almacenamiento estable. Tras el fallo, el sistema se reconfigura para aislar el componente erróneo, recupera el último estado consistente y reanuda las operaciones (esto se denomina rollback recovery) Quién: El humano: administrador o propietario del trabajo El sistema: distintas políticas para recuperar 56

57 Recuperación n hacia atrás 57

58 Recuperación n inversa Consiste en retroceder a un estado anterior correcto y ejecutar un segmento de programa alternativo (con otro algoritmo) El punto al que se retrocede se llama punto de recuperación (recovery point) La acción de guardar el estado se llama chekpointing No es necesario averiguar la causa ni la situación del fallo Sirve para fallos imprevistos No puede deshacer los errores que aparecen en el sistema controlado! Tiempo Punto de Recuperación Objetivo (RPO) Estado Consistente (Checkpoint) Crash 58

59 Modelo de Recuperación n transparente El sistema: Se pueden utilizar distintas políticas para recuperar Recuperar los procesos en otros recursos del sistema y continuar la ejecución: ejemplo: RADIC Recuperar los procesos en un nuevo conjunto de recursos, si es posible: Ejemplo RADIC-X Recuperar los procesos en el mismo recurso al que fue asignado, después de reparado: Ejemplo RADIC-X Poner los procesos en la cola y esperar a que se le asignen recursos para continuarlo: Ejemplo: FTDR 59

60 Checkpointing Checkpoint-Recovery: da a una aplicación o sistema la capacidad de salvar su estado, y tolerar fallos permitiendo que una ejecución que ha fallado, recuperar en un estado salvado en un punto anterior. Ideas claves Salvar estado de ejecución Proporcionar mecanismos de recuperación en presencia de fallos Permitir tolerancia de fallos previstos. Proporciona el mecanismo para la migración de proceso en los sistemas distribuidos por razones de la tolerancia de avería o balancear de la carga 60

61 Checkpoint Recovery La imagen básicab Una vez el fallo ha sido detectado y el proceso se ha recuperado, en su último checkpoint es necesario asegurar la consistencia del estado causada por la interdependencia entre tareas 61

62 Introducción. Conceptos básicos. Organización Definición de fallo, error y avería Garantía de funcionamiento Medidas de fiabilidad Técnicas para aumentar la fiabilidad de un sistema: Técnicas de Redundancia: Checkpoint Modelos, terminología y aspectos generales del rollbackrecovery 62

63 Checkpoint Checkpoint: Lugar en el programa, en que se interrumpe el procesamiento normal, para preservar la información del estado necesaria para permitir reasumir el procesamiento en un instante posterior Periódicamente se salva el estado del proceso Después del fallo, el proceso puede ser recomenzado desde un estado conocido almacenando Requiere que el proceso se suspenda durante el tiempo que se almacena su estado Consume recursos de E/S Checkpointing: es el proceso de salvar la información del estado 63

64 Checkpointing-Recovery Checkpoint: da a una aplicación o sistema la capacidad de salvar su estado y tolerar fallos capacitando una fase ejecutiva de tratamiento de fallo para recuperar a un estado salvado anterior al fallo. Rollback recovery: El proceso de reasumir un cómputo volviendo al estado salvado Cuestiones claves Salvar estado periódicamente Proporcionar mecanismos de recuperación en la presencia de fallos que garanticen la consistencia Proporcionar mecanismos para migración de procesos en sistemas distribuidos Puede requerir balanceo de carga 64

65 Aspectos de checkpointing Frecuencia de checkpointing: relacionado con el overhead. Depende de la probabilidad de fallo y la importancia de la computación. Nos interesa Overhead mínimo Recuperación rápida Tiempo de Computación perdida: poca Contenido del checkpointing: el estado del proceso debe salvarse en un almacenamiento estable 65

66 Algoritmos de checkpointing Algoritmos de checkpointing Sistemas uniprocesador Sistemas Multiprocesador Enfoques estáticos Enfoques Dinámicos Enfoques estáticos Enfoques Dinámicos Métodos basados en grafos Sistemas con Memoria Compartida Métodos basados En el compilador Enfoques basados en cache Sistemas con Memoria Compartida Distribuida Enfoques basados en memoria Sistemas de Paso de Mensajes 66

67 Clasificación: Checkpoint / Restart (Elnozahy 96) Checkpoint Coordinación Checkpoint distribuido Salvar el estado No coordinado Inducido por comunicación Coordinado Aplicación Sistema No bloqueante Bloqueante 67

68 Checkpoint Coordinado No Bloqueante (Chandy/Lamport). Todos los procesos coordinan sus checkpoints, de forma que el estado global del sistema es coherente (Chandy & Lamport Algorithm) El objetivo es hacer un checkpoint de la aplicación cuando no exista tránsito de mensajes entre dos nodos sincronización global flush de la red Gran overhead en ejecución libre de fallos En el caso de fallo, todos los procesos hacen roll back a sus checkpoints Alto coste para recuperación de fallo Eficiente cuando la frecuencia es baja No escalable restart detección/ global stop fallo Ckpt Sync Nodos 68

69 Checkpoint coordinado No bloqueante 69

70 Checkpointing Co-ordinado ordinado Bloqueante: Barreras P Q R Barrier Barrier Barrier Many programs are bulk-synchronous (BSP model of Valiant) At barrier, all processes can take checkpoints. assumption: no messages are in-flight across the barrier Parallel program reduces to sequential state saving problem But many new parallel programs do not have global barriers.. 70

71 Checkpoint Inducido por Comunicación No requiere sincronización global para proporcionar una coherencia global El nº de checkpoint forzado incrementa linealmente con el nº de nodos No escala Es impredecible la frecuencia de checkpoint Detección de un posible estado inconsistente obliga a checkpoint bloqueante de algunos procesos Gran overhead en ejecución libre de fallos Poco usado en la práctica 71

72 Checkpoint no coordinado No existe una sincronización global (escalable) Nodos: pueden hacer checkpoint en cualquier momento (independientemente de los otros) Necesita log no determinístico de eventos: Mensajes en transito restart detección fallo Ckpt Nodos 72

73 Checkpoint en Computadores Paralelos Problema: existen múltiples flujos de ejecución y no existe un reloj global Es difícil iniciar checkpoints en todos los flujos de ejecución en el mismo instante de tiempo para tener checkpoint concurrentes que permitan un rollback recovery consistente 73

74 Consistencia en Sistemas con Paso de Mensaje Estado consistente: Debe reflejar la recepción de mensajes Métodos de checkpointing en clusters Debemos tener en cuenta los mensajes y sus dependencias Después de un fallo deberían ejecutarse en el mismo orden previo al fallo Este mensaje no está en el estado del remitente 74

75 Definiciones Relación de Precedencia: ocurren antes (LAMPORT): a y b son 2 eventos del mismo proceso si a ocurre antes que b : a b si el evento a envía un mensaje y b es el evento que recibe dicho mensaje: a b Eventos concurrentes: 2 eventos a y son concurrentes : a b si a / b yb / a Checkpoint local: evento que guarda el estado de un proceso en un procesador en un instante dado Checkpoint global: conjunto de checkpoints locales, uno de cada procesador Checkpoint global consistente: Un estado global es consistente si todos los eventos incluidos forman un conjunto concurrente. Un Checkpoint global consistente es un conjunto de checkpoint locales, uno de cada procesador, tal que cada checkpoint local es concurrente a cada uno de los otros checkpoint locales Rollback recovery: es un proceso de reasumir/recuperar un computo de un checkpoint global consistente 75

76 Estados consistentes Dos procesos P y Q, cada uno tiene 2 checkpoint realizados El mensaje m es enviado por P a Q Conjuntos de checkpoint que representan estados consistentes del sistema: {P_1, Q_1}: Ningún checkpoint tiene información sobre m {P_2, Q_2}: P_2 indica que m fue enviado; Q_2 indica que fue recibido {P_2, Q_1}: P_2 indica que m fue enviado; Q_1 no tiene información sobre la recepción de m P Q P_1 Q_1 m Q_2 P_2 Tiempo 76

77 Estados inconsistentes: Mensajes huérfanos Mensajes huérfanos: {P_1, Q_2} es un estado inconsistente; P_1 no recuerda el envío de m, mientras Q_2 recuerda haberlo recibido Línea de recuperación: El conjunto de checkpoints que representan un estado del sistema consistente El rollback debe volver a un estado consistente, es decir buscar una línea de recuperación para hacer el restart a partir de ahí {P_1, Q_1}: Corte consistente {P_2, Q_1}: P no retransmite m ; Q no recuerda haber recibido m. El proceso de recuperación necesita añadir al checkpoint un log de mensajes separado recordando lo recibido por Q 77