Computación de Alta Performance Curso 2009 TOLERANCIA A FALLOS COMPUTACIÓN DE ALTA PERFORMANCE 2009 TOLERANCIA A FALLOS

Tamaño: px

Comenzar la demostración a partir de la página:

Download "Computación de Alta Performance Curso 2009 TOLERANCIA A FALLOS COMPUTACIÓN DE ALTA PERFORMANCE 2009 TOLERANCIA A FALLOS"

Lorenzo Rico Caballero
hace 8 años
Vistas:

1 Computación de Alta Performance Curso 2009 TOLERANCIA A FALLOS

2 INTRODUCCIÓN Clusters cada vez más grandes y complejos. Tiempo de cómputo ininterrumpidos cada vez más largos. Componentes trabajando cerca de los límites tecnológicos. Necesidad de Fiabilidad y Disponibilidad del sistema. La probabilidad de fallos se incrementa al tener más componentes. Por lo tanto es necesario considerar técnicas de Tolerancia a Fallos.

Componentes trabajando cerca de los límites tecnológicos.

3 TIPOS DE CLUSTERS Clusters de alto rendimiento (High Performance Cluster): Comunicar muchos computadores que cooperen en equipo y obtengan la solución al problema en forma rápida. Clusters de alta disponibilidad (High Availability Cluster): Conseguir un sistema de computadores más fiables, compartiendo trabajos y con un funcionamiento redundante, de tal manera que si un ordenador falla otro se encarga de realizar su trabajo. Alta disponibilidad: Procesamiento: Cluster, nodo, red de interconexión. Datos: Almacenamiento (RAID).

Clusters de alta disponibilidad (High Availability Cluster): Conseguir un sistema de computadores más fiables, compartiendo trabajos

4 NECESIDAD DE TOLERANCIA A FALLOS Reactores nucleares, plantas químicas, equipos médicos, aplicaciones financieras Un mal funcionamiento en este tipo de aplicaciones puede generar una catástrofe. La probabilidad de fallo debe ser extremadamente baja. Orientaciones del uso: Alto rendimiento (HP): Ciencias de la vida. Alto throughput (HT): Biología digital. Alta disponibilidad (HA): e-commerce, etc.

catástrofe. La probabilidad de fallo debe ser extremadamente baja.

5 FIABILIDAD Medida del éxito con el que el sistema cumple con alguna de las especificaciones obligatorias de su comportamiento. 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, y son resultados de errores internos. Las causas mecánicas o algorítmicas de los errores se llaman fallos (faults).

Avería (failure): Cuando el comportamiento de un sistema se desvía del especificado, se dice que se ha

6 ALTA DISPONIBILIDAD Intentar mantener en todo momento la prestación del servicio encubriendo los fallos internos que se pueden producir.

7 ALTA DISPONIBILIDAD 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. MTBF (Mean Time Between Failure): Tiempo medio entre los defectos del sistema. MTBI (Mean Time Between Interrupts): Tiempo medio entre las interrupciones del sistema.

MTTR (Mean Time To Repair): Tiempo medio para reparar el sistema.

8 DISPONIBILIDAD disp = MTTF / MTBF MTBF = MTTF + MTTR Ejemplo: disp = MTTF / (MTTF + MTTR) Un elemento tiene un MTBF de horas y se tarda típicamente 4 horas en restaurar cuando ocurre un fallo. disp = / ( ) = 99,996 %

MTBF de 100000 horas y se tarda típicamente 4 horas en

9 AUMENTAR DISPONIBILIDAD Opciones: Incrementar MTTF: incrementar la fiabilidad (difícil). Reducir MTTF: Reducir el tiempo de reparación es más habitual en clusters. Componentes de hardware redundantes. Programación crítica sujeta a votación (redundancia de ejecución con posterior votación de los resultados). Disponibilidad Tiempo de fallo por año 99 3,6 días 99,9 8,5 horas 99,99 1 hora 99,999 5 minutos

10 OVERHEAD DE TENER TOLERANCIA Overhead que se introduce en cada una de las fases de la tolerancia a fallos: Protección: redundancia, envío, almacenamiento. Checkpoint overhead: es el incremento en el tiempo de ejecución de la aplicación debido a la realización del 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.

Latencia del checkpoint: es el tiempo necesario para salvar el checkpoint (depende del tamaño del checkpoint).

11 OVERHEAD / COSTO DE PREVENCIÓN Componente de hardware redundantes. Hot standby: El componente hardware está listo (hot o spare) para tomar el relevo inmediatamente cuando falla el componente primario. Sustitución mutua: Todos los componentes son primarios en el sentido que están en operación simultaneamente. Cuando uno falla los otros se hacen cargo de las tareas. Tolerante a fallos: Todos los componentes operan en redundancia (ejecutan los mismos trabajos). Infraestructura de alta disponibilidad (middlware), que incluye servicio de Protección: Checkpoint, o replicación de datos. Recuperación tras fallo Tolerancia a fallos.

Sustitución mutua: Todos los componentes son primarios en el sentido que están en operación simultaneamente.

12 DETECCIÓN DE ERRORES Los fallos no pueden ser observados en 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. Heartbeat: Mecanismo de diagnostico de fallo: se envían un flujo de mensajes de control entre los componentes del sistema. Temporizadores de guardia: watchdogs. Otros fallos de comunicación. Cuando de detecta un 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 del componente fallido.

Heartbeat: Mecanismo de diagnostico de fallo: se envían un flujo de mensajes de control entre los componentes del sistema.

13 CHECKPOINTS Consiste en que periódicamente se salva el estado del proceso, de este modo el proceso puede ser recomenzado desde un estado conocido antes del fallo. Requiere que el proceso se suspenda durante el tiempo que se almacena su estado. Consume recursos de E/S. Ideas claves: Salvar estado de ejecución. Proporcionar mecanismos de recuperación en presencia de fallos. Permitir tolerancia a 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 la carga.

Ideas claves: Salvar estado de ejecución. Proporcionar mecanismos de recuperación en presencia de fallos.

14 REDUNDANCIA Redundancia estática: Los componentes redundantes están siempre activos. Se utilizan para enmascarar los fallos. Redundancia dinámica: Los componentes redundantes se activan cuando se detecta un fallo. Se basa en la detección y posteriormente recuperación del fallo.

Redundancia dinámica: Los componentes redundantes se activan cuando

15 ESTRATEGIAS DE RECUPERACIÓN Recuperación hacia atrás: Los procesos en ejecución periódicamente guardan un estado consistente (checkpoint) en un sistema de almacenamiento estable. Tras el fallo, el sistema se reconfigura para aislar el componente erróneo, recupera el último checkpoint y reanuda las operaciones (esto se le denomina rollback recovery). Recuperación hacia adelante: El sistema no recupera el último checkpoint, sino que utiliza la información de diagnostico de fallo e intenta reconstruir un estado de ejecución válido (habitual en sistemas de tiempo real).

Tras el fallo, el sistema se reconfigura para aislar el componente erróneo, recupera el último checkpoint y reanuda las operaciones (esto se

16 ESTRATEGIAS DE RECUPERACIÓN

17 CHECKPOINT CON SISTEMAS DE MENSAJES Métodos de checkpoints en cluster. Se debe tener en cuenta los mensajes y sus dependencias. P 0 P 1 P 2 P 3 t

18 OPCIONES PARA EL CHECKPOINTS Checkpoints dirigidos desde el sistema. Checkpoints dirigidos desde la aplicación. Checkpoints incrementales dirigidos desde el sistema. Checkpoints en memoria. Frecuencia del checkpoint: Depende de la probabilidad de fallo e importancia del computo. Interesa: Overhead mínimo. Recuperación rápida. Tiempo de computación perdida: poca. Contenido del checkpoint: el estado del proceso se debe salvar en un almacenamiento estable.

Frecuencia del checkpoint: Depende de la probabilidad de fallo e importancia del computo.

19 CHECKPOINTS EN COMPUTADORES PARALELOS Problema: existen múltiplos 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 checkpoints concurrentes que permitan una vuelta atrás consistente. Los procesos además del checkpoint tienen una bitácora de mensajes enviados y recibidos de forma de reconstruir el estado.

Es difícil iniciar checkpoints en todos los flujos de ejecución en el mismo instante de tiempo para

Documentos relacionados

COMPUTACIÓN DE ALTA PERFORMANCE

COMPUTACIÓN DE ALTA PERFORMANCE 2011 1 TOLERANCIA A FALLOS COMPUTACIÓN DE ALTA PERFORMANCE Curso 2011 Sergio Nesmachnow (sergion@fing.edu.uy) Santiago Iturriaga (siturria@fing.edu.uy) Gerardo Ares (gares@fing.edu.uy)