4. Tolerancia a fallos 4.1 Introducción 4.2 Fiabilidad, avería y fallos 4.3 Prevención y tolerancia a fallos 4.4 Redundancia dinámica del software 4.5 Bloques de recuperación 4.6 Componentes de sistemas tolerantes a fallos D.S.T.R. Tolerancia a fallos- 1/12 4.1. Introducción Fallos de funcionamiento de STRs: ● Especificación inadecuada. ● Errores en el diseño de los componentes de software. ● Fallos introducidos por averías en hardware. ● Fallos de comunicación de los sistemas. Dos enfoques: ● Técnicas de diseño ● Manejo de excepciones D.S.T.R. Tolerancia a fallos- 2/12 4.2. Fiabilidad, avería y fallos Fiabilidad (reliability) de un sistema: conformidad a la especificación de su comportamiento. Especificación: completa, consistente, comprensible y no ambigua. Avería (failure): desviación del comportamiento de un sistema con respecto a su especificación. sistema altamente fiable = sistema con baja tasa de averías Averías provienen de problemas internos inesperados: errores Causas de los errores: fallos. Tipos de fallos: ● Transitorios ● Permanentes ● Intermitentes D.S.T.R. Tolerancia a fallos- 3/12 4.3. Prevención y tolerancia a fallos Prevención de fallos: evitar fallos antes del funcionamiento Tolerancia a fallos: comportamiento correcto pese a los fallos 4.3.1. Prevención de fallos Evitar fallos: impedir que se introduzcan. A nivel software: ● Reutilizar componentes fiables. ● Utilizar metodologías de diseño rigurosas. ● Utilizar lenguajes de programación y entornos de desarrollo adecuados. Eliminar fallos: localizar y eliminar fallos en el sistema. A nivel software: ● Revisiones de diseño. ● Verificación de programas. ● Inspecciones de código. ● Pruebas del sistema. Pruebas del sistema: no son suficientes para eliminar todos los fallos ● No demuestran la ausencia de fallos ● Condiciones realistas difíciles => simulación ● Problemas de especificación aparecen en funcionamiento D.S.T.R. Tolerancia a fallos- 4/12 4.3.2. Tolerancia a fallos Necesaria por fallos no encontrados o fallos de harware Tolerancia completa (full fault tolerance): el sistema sigue funcionando, al menos durante un tiempo, sin perder funcionalidad o prestaciones. ● Degradación aceptable (graceful degradation): el sistema sigue funcionando con una degradación parcial en su funcionalidad o prestaciones hasta que el fallo sea solucionado. ● Parada segura: el sistema mantiene su integridad deteniéndose de forma correcta. ● D.S.T.R. Tolerancia a fallos- 5/12 4.3.1. Redundancia Tolerancia a fallos => introducción de elementos adicionales o redundantes en el sistema Objetivo: maximizar fiabilidad, minimizar redundancia Conveniente aislar componentes redundantes Redundancias (harware): Redundancia estática: componentes redundantes siempre activos. Sistema de votación TMR (redundancia modular triple) o NMR ● ● Redundancia dinámica: componentes activados en fallos Redundancias (software): Redundancia estática: distintas versiones desarrolladas independientemente ● Redundancia dinámica: componentes activados en fallos. A continuación... ● D.S.T.R. Tolerancia a fallos- 6/12 4.4. Redundancia dinámica del software Cuatro etapas: ● Detección del error. ● Evaluación y confinamiento de los daños. ● Recuperación del error. ● Reparación del fallo. 4.4.1. Detección de errores Detección por el entorno: por hardware o sistema operativo Detección por la aplicación: ● Comprobación mediante replicación: varias versiones ● Comprobación mediante temporización: watchdog timer o plazo de ejecución ● Comprobación por inversión: cuando hay relación isomórfica entradasalida ● Comprobación de código: información redundante en los datos ● Comprobación de valores o estado: introducción de aserciones D.S.T.R. Tolerancia a fallos- 7/12 4.4.2. Evaluación y confinamiento de daños Minimización del efecto del error: ● Descomposición modular ● Acciones atómicas ● Mecanismos de protección de acceso a recursos 4.4.3. Recuperación de errores Una vez detectado y confinado el error Recuperación: paso de estado erróneo a correcto (a veces con funcionalidad reducida) Recuperación directa o hacia adelante (forward): avanza a estado correcto mediante correcciones ● Recuperación inversa o hacia atrás (backward): vuelve a un punto de recuperación generado mediante checkpointing ● D.S.T.R. Tolerancia a fallos- 8/12 Efecto dominó: Solución: establecer puntos de recuperación globales Conjunto de puntos de recuperación globales: línea de recuperación D.S.T.R. Tolerancia a fallos- 9/12 4.4.4. Reparación de fallos Erradicar el fallo: ● Localizar el fallo ● Eliminar el fallo Problema en sistemas que no se apagan o desactivan 4.5. Bloques de recuperación Técnica de tolerancia a fallos que usa bloques: ● La entrada es un punto de recuperación ● La salida realiza un test de aceptación Aceptación negativa => bloque alternativo Todos los bloques negativos => recuperación a nivel más alto Integra: detección de fallos, confinamiento de daños y recuperación del error. No integra reparación del fallo Test de aceptación: exhaustividad <-> tiempo de ejecución D.S.T.R. Tolerancia a fallos- 10/12 4.6. Componentes de sistemas tolerantes a fallos Excepción: mecanismo de lenguajes de programación para recuperación directa de fallos Fallo => la excepción se eleva al código invocante de la actividad errónea Recuperación del fallo: manejador de la excepción Dos tipos de excepciones: ● Excepciones de interfaz: peticiones de servicio ilegales ● Excepciones de avería: funcionamiento del componente invocado Idealmente, antes de elevar la excepción el componente debe regresar a estado que permita atender futuras peticiones D.S.T.R. Tolerancia a fallos- 11/12 Componente tolerante a fallos ideal: D.S.T.R. Tolerancia a fallos- 12/12