Sistemas de Operación II

Presentación del tema: "Sistemas de Operación II"— Transcripción de la presentación:

1 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

2 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

3 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

4 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

5 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

6 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

7 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

8 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

9 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

10 Redundancia Carlos Figueira/USB

11 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

12 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

13 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

14 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

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

16 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

17 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

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

19 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

20 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

21 Recuperación de transacciones
Carlos Figueira/USB

22 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

23 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

24 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

25 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

26 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

27 Mecanismos de Recuperación
Carlos Figueira/USB

28 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

29 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

30 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

31 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

32 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

33 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

34 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

35 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

36 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

37 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

38 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

39 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

40 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

41 Acuerdos en sistemas que fallan
Carlos Figueira/USB

42 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

43 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

44 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