Sistemas de Operación II Tolerancia a Fallas y Recuperación Prof. Carlos Figueira Basado en material de Yudith Cardinale (USB) Andrew Tanembaum y Marteen van Steen

Contenido Conceptos Básicos de Tolerancia a Fallas Redundancia Réplicas Recuperación de transacciones Listas de Intención Mecanismos de recuperación Uso de bitácoras Versiones Sombras Acuerdos en sistemas que fallan Carlos Figueira/USB

Tolerancia a Fallas Es la capacidad de que un sistema siga operando en presencia de fallas de uno o más componentes En un Sistema Distribuido, pueden ocurrir fallas parciales: las fallas totales son muy raras Falla de un componente puede afectar a otros Objetivo: recuperarse automáticamente de fallas parciales sin afectar rendimiento global Carlos Figueira/USB

Conceptos básicos Disponibilidad: propiedad del sistema de estar listo para ser usado en cualquier momento Confiabilidad: propiedad del sistema de ejecutar servicios de manera continua, sin fallas Seguridad: si sistema falla temporalmente, nada catastrófico sucederá Facilidad de Mantenimiento (maintainability): qué tan fácil se repara sistema cuando falla Notas: Alta disponibilidad no implica alta confiabilidad ¡La recuperación automática no es tan fácil! Carlos Figueira/USB

Conceptos básicos Falla del Sistema <= Error <= Falla externa Sistema falla cuando no cumple con objetivos, no satisface a sus usuarios Un error es un estado del sistema que produce una falla La causa de un error es llamada “falla externa” Determinar la falla externa es importante, pero no siempre ayuda. Cambiar las condiciones del momento para prevenir un error no funciona Carlos Figueira/USB

Conceptos básicos Sistemas Tolerantes a Fallas no las previenen, sino que las controlan (anulan o mitigan sus efectos) Los Sistemas Tolerantes a Fallas proveen los servicios en presencia de fallas Clasificación de fallas externas: Transitorias: ocurren una vez y desaparecen Intermitentes: ocurren, desaparecen, ocurren nuevamente, y así sucesivamente Permanentes: la falla ocurre y no desaparece Carlos Figueira/USB

Modelos de fallas del sistema Fallas por muerte (crash): el servidor se para, pero trabaja correctamente hasta ese momento Fallas por omisión: servidor falla (deja de responder) a solicitudes entrantes De recepción: falla recibiendo mensajes De envío: falla enviando mensajes Fallas de temporización: la respuesta del servidor cae fuera del intervalo de tiempo especificado Carlos Figueira/USB

Modelos de fallas del sistema Fallas de respuesta: la respuesta del servidor es incorrecta De valor: el valor de la respuesta es incorrecto De transición de estados: el servidor se desvía del flujo correcto de control Fallas Arbitrarias (bizantinas): un servidor puede producir respuestas arbitrarias en momentos arbitrarios Carlos Figueira/USB

Modelos de fallas del sistema Fallo-detención (fail-stop): caída detectable, se obtiene notificación Silenciosas: falla se produce sin anuncios. Puede confundirse con servidores lentos Seguras (fail-safe): servidor produce salidas que se reconocen como fallas Bizantinas: servidor produce salida errónea que se confunde con salida correcta. Opciones: tratar de precisar mediante sondeo, o parar y volver a arrancar el sistema Carlos Figueira/USB

Redundancia Carlos Figueira/USB

Enmascaramiento de fallas Redundancia permite ocultar fallas. Hay tres tipos Información: se agrega información adicional para detectar/corregir fallas (código de Hamming, bits de paridad, etc.) Tiempo: una acción se puede repetir si es necesario (transacciones u operaciones idempotentes) Física: se agregan equipos o procesos extras para sustituirlos por el componente que falle Carlos Figueira/USB

Redundancia Física La más usada en biología, aviones, deportes y circuitos electrónicos El modelo TMR (Redundancia Modular Triple) de los circuitos electrónicos se puede aplicar a SD Carlos Figueira/USB

Redundancia Pueden usarse grupos de procesos y comunicación en grupo ¿Cuánta replicación es necesaria si se usan grupos de procesos? Un sistema es k-tolerante a fallas si continúa funcionando aunque fallen k componentes La redundancia con grupo de procesos requiere multicast atómico Carlos Figueira/USB

Enfoques de replicación por grupos Protocolo basado en respaldo primario (replicación pasiva). Se implementa con grupos jerárquicos Protocolo de escritura replicada: Se implementa con grupos planos (como TMR) Carlos Figueira/USB

Replicación pasiva C Prin Resp El cliente interactúa con Principal/Primario, que se encarga de actualizar servidores de respaldo Carlos Figueira/USB

Replicación pasiva Petición: va del cliente al principal (lleva id de petición) Coordinación: principal acepta peticiones en forma atómica y en orden Ejecución: principal ejecuta petición y guarda respuesta Acuerdo: para actualizar, se envían cambios a todos los respaldos (atómicamente) Respuesta: principal responde al cliente Carlos Figueira/USB

Replicación pasiva Requiere algoritmos de elección de coordinador cuando falla principal Es necesario identificar requerimientos de manera que nuevo principal detecte retransmisiones Desventaja: sobrecarga relativamente grande para principal Para descargar a principal, lecturas pueden ser satisfechas por respaldos ¿Puede soportar fallas silenciosas y bizantinas? Carlos Figueira/USB

Replicación activa C Serv Proxy La interacción se hace directamente con todos los servidores simultáneamente Carlos Figueira/USB

Replicación activa (escrituras replicadas) Petición: cliente/proxy envía requerimiento a grupo (multicast) Coordinación: sistema de com. en grupo reparte petición (multicast atómico y ordenado) Ejecución: todos ejecutan petición Acuerdo: no es necesario, debido a comunicación atómica y ordenada Respuesta: todos envían respuesta a cliente/proxy Carlos Figueira/USB

Replicación activa (escrituras replicadas) Cliente/proxy puede obtener la primera respuesta y obviar las demás, o puede decidir en base a respuesta más común de las que recibe Provee consistencia secuencial ¿Puede soportar fallas silenciosas y bizantinas? Carlos Figueira/USB

Recuperación de transacciones Carlos Figueira/USB

Recuperación de transacciones Consiste en asegurar la atomicidad de las transacciones en presencia de fallas del servidor Implica permanencia (durabilidad): los datos son salvados en almacenamiento permanente y no pueden revertirse Interviene Administrador de Recuperación Carlos Figueira/USB

Administrador de recuperación Salva datos en archivo de recuperación (permanente) de transacciones comprometidas Restaura datos del servidor después de caída Reorganiza archivo de recuperación para mejorar desempeño en recuperación Recobra espacio de almacenamiento (archivo de recuperación) Carlos Figueira/USB

Listas de intención Usadas para que cada servidor mantenga registro de datos accedidos por transacciones Durante progreso de transacción, operaciones se aplican a conjunto privado de versiones tentativas Cada servidor registra lista de intención (write- ahead log) de cada transacción activa Contiene lista de nombres y valores de datos modificados por la transacción Carlos Figueira/USB

Listas de intención Cuando una transacción se compromete (commit), el servidor usa lista de intención para identificar datos afectados versión comprometida previamente de cada dato es reemplazada por versión tentativa de la transacción; el nuevo valor es escrito en archivo de recuperación del servidor Cuando aborta transacción, servidor usa lista de intención para borrar versiones tentativas Carlos Figueira/USB

Contenido de Lista de Intención Tipo de entrada Descripción Dato Valor Estado de transacción Tid, estado (lista, espera, comprometida, abortar), otros valores Lista de intención Tid y secuencia de intenciones que consisten de: <id dato>, <posición de valor del dato en archivo de recuperación> Carlos Figueira/USB

Mecanismos de Recuperación Carlos Figueira/USB

Mecanismos de recuperación: bitácoras (logging) Archivo de recuperación representa una bitácora o registro histórico, con todas las transacciones realizadas por el servidor Contiene valores de datos, registros de estados de transacciones y listas de intención Orden de las entrada en la bitácora refleja orden en el cual transacciones han sido preparadas, comprometidas o abortadas en servidor Archivo de recuperación contendrá foto de valores de datos en servidor, seguida por historia de transacciones posteriores a la foto (punto de control) Carlos Figueira/USB

Ejemplo del mecanismo de bitácoras Transacción T Transacción U retirar(A,4) retirar(C,3) depositar(B,4) depositar(B,3) balance=A.leer() 100 A.escribir(balance-4) 96 balance=C.leer() 300 C.escribir(balance-3) 297 balance=B.leer 200 B.escribir(balance+4) 204 B.escribir(balance+3) 207 Carlos Figueira/USB

Ejemplo del mecanismo de bitácoras Antes de T y U T y U comenzaron P0 P1 P2 P3 P4 P5 P6 P7 Trans T preparada <A,P1> <B,P2> P0 Trans U preparada <C,P5> <B,P6> P4 Dato A 100 Dato B 200 Dato C 300 Dato A 96 Dato B 204 Trans T completa P3 Dato C 297 Dato B 207 Punto de control Apuntadores a la posición del estado previo de la transacción Pi: posición i en bitácora Fin de registro de bitácora Carlos Figueira/USB

Proceso de recuperación usando registro de bitácoras Durante operación normal de servidor, se invoca Administrador de Recuperación cuando: Una transacción se prepara para completar se agregan todos los datos tentativos en su lista de intención al archivo de recuperación, seguido por el estado actual (preparado, listo) y lista de intención Una transacción se completa o aborta; se agrega estado a archivo de recuperación La operación de agregar registro al archivo de recuperación se asume atómica. Si falla servidor, sólo la última escritura puede estar incompleta Carlos Figueira/USB

Proceso de recuperación usando registro de bitácoras Cuando un servidor es restaurado: Coloca los valores iniciales por defecto de sus datos Llama al Administrador de Recuperación (AR) AR restaura datos del servidor de manera que incluyan todos los efectos de transacciones comprometidas ejecutadas en el orden correcto y ninguno de los efectos de transacciones incompletas o abortadas Información más reciente sobre transacciones está al final de bitácora Recuperación se hace recorriendo bitácora desde final hasta inicio Carlos Figueira/USB

Organización del archivo de recuperación Administrador de recuperaciones debe organizar archivo de recuperación para que el proceso sea rápido, y optimizar uso de espacio Información requerida: copia de las versiones comprometidas de todos los datos del servidor Cuando ocurre una recuperación, todas las transacciones no consumadas son marcadas como abortadas en la bitácora, su lista de intención descartada. Carlos Figueira/USB

Registro de puntos de control (checkpointing) Proceso de escribir a un nuevo archivo de recuperación Valores actuales comprometidos de datos de un servidor Registros de estados de transacción Listas de intención de transacciones que aún no han sido completadas Punto de control: Información almacenada por el proceso de Registro de Punto de control. Carlos Figueira/USB

Puntos de control Objetivo: reducir el número de transacciones a manejar durante recuperación El Registro de Puntos de control se hace: Después de una recuperación Antes de comenzar nueva transacción Periódicamente, durante actividad normal del servidor El Punto de control se escribe en archivo de recuperación. Archivo de recuperación actual permanece activo durante Registro de Punto de control Carlos Figueira/USB

Registro de Puntos de control Archivo de recuperación actual Items de datos del servidor D . . . Pasó durante Registro de Punto de control Archivo de recuperación futuro Marca de Punto de control Foto de D Pasó durante Registro de Punto de control Estados no comprometidos Carlos Figueira/USB

Mecanismos de recuperación: versiones sombra Forma alterna de organizar archivo de recuperación Usa mapa para localizar versiones de los datos en un archivo llamado almacenamiento de versiones (version store) Mapa asocia id de datos del servidor con posición de sus versiones en ese archivo Versiones escritas por cada transacción se denominan versiones sombra mientras no se complete transacción Carlos Figueira/USB

Mecanismos de recuperación: versiones sombra Registros de estados de transacción, listas de intención: salvadas en archivo estado de transacción. Lista de intención representa parte del mapa que será alterada por transacción cuando se completa Cuando se completa transacción, se crea nuevo mapa copiando mapa viejo y agregando posiciones de versiones sombra. Al completarse, se reemplaza mapa viejo por el nuevo, de manera atómica Carlos Figueira/USB

Ejemplo de versiones sombra Transacción T Transacción U retirar(A,4) retirar(C,3) depositar(B,4) depositar(B,3) balance=A.leer() 100 A.escribir(balance-4) 96 balance=C.leer() 300 C.escribir(balance-3) 297 balance=B.leer 200 B.escribir(balance+4) 204 B.escribir(balance+3) 207 Carlos Figueira/USB

Ejemplo de versiones sombra Mapa antes de T y U Mapa después de completar T A --> P0 B --> P1 C --> P2 A --> P3 B --> P4 C --> P2 Archivo de almacenamiento de versiones P0 100 P1 200 P2 300 P3 96 P4 204 P5 296 P6 207 Punto de control Archivo de estados de transacciones T preparado <A,P3> <B,P4> T completado U preparado <B,P6> <C,P5> Carlos Figueira/USB

Acuerdos en sistemas que fallan Carlos Figueira/USB

Acuerdos en sistemas que fallan Algoritmos de acuerdo en sistemas distribuidos son muy comunes: C2F, elección coordinador, sincronización y exclusión mutua, etc. Las fallas pueden afectar decisiones distribuidas Objetivo principal de algoritmos de acuerdos distribuidos: llegar a un consenso con procesos sobrevivientes (fallas silenciosas) o confiables (fallas bizantinas) Escenarios: procesos no confiables ó comunicación no confiable Carlos Figueira/USB

Acuerdos en sistemas que fallan Procesos confiables y comunicación no confiable Imposible llegar a un acuerdo. Ejemplo: problema de los dos ejércitos Líneas de comunicación confiables, procesos pueden fallar de manera bizantina Se puede llegar a un acuerdo. Ejemplo: problema de los generales bizantinos Carlos Figueira/USB

Acuerdos en sistemas que fallan Problema de los generales bizantinos Si se tienen 3m+1 generales, y sólo m traidores, se puede llegar a un acuerdo (Lamport, Shostak y Pease) En sistemas asíncronos y retardos de comunicación no acotados, no es posible llegar a acuerdos con fallas bizantinas o silenciosas. Carlos Figueira/USB