Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Curso 2012-2013
Tolerancia a fallos
Contenido
Conceptos bsicos sobre fiabilidad y tolerancia a fallos Tolerancia a fallos del software Replicacin Consistencia Multicast
Tolerancia a fallos
Sistema tolerante a fallos Sistema que posee la capacidad interna para asegurar la ejecucin correcta y continuada de un sistema a pesar de la presencia de fallos HW o SW Objetivo Conseguir que un sistema sea altamente fiable
Conceptos bsicos
La fiabilidad (reliability) de un sistema es una medida de su conformidad con una especificacin autorizada de su comportamiento. Un sistema es fiable si cumple sus especificaciones. Una avera o defecto (failure) es una desviacin del comportamiento de un sistema respecto de su especificacin. Las averas se manifiestan en el comportamiento externo del sistema, pero son el resultado de errores (errors) internos. Las causas mecnicas o algortmicas de los errores se denominan fallos (faults). Los fallos pueden ser consecuencia de averas en los componentes del sistema.
Flix Garca Carballeira Sistemas Distribuidos (2012-2013) 5
Relaciones causa-efecto
fallo componente, diseo error avera, defecto
Los fallos pueden ser pequeos, pero los defectos muy grandes Un simple bit puede convertir el saldo de una cuenta bancaria de positivo a negativo
Ejemplo
Fichero corrupto almacenado en el disco. Consecuencia: avera en el sistema que utiliza el fichero. Qu provoc el fallo? Error en el programa que escribi el fichero (fallo de diseo). Problema en la cabeza del disco (fallo en el componente). Problema en la transmisin del fichero por la red (fallo HW) El error en el sistema podra ser corregido (cambiando el fichero) pero los fallos podran permanecer. Importante distinguir entre fallos y errores.
Ejemplos de fallos
Explosin del Ariane 5 en 1996 Enviado por la ESA en junio de 1996 (fue su primer viaje) Coste del desarrollo: 10 aos y 7000 millones de dlares Explot 40 segundos despus del despegue a 3700 metros de altura. El fallo se debi a la prdida total de la informacin de altitud. Causa: error del diseo software El SW del sistema de referencia inercial realiz la conversin de un valor real en coma flotante de 64 bits a un valor entero de 16 bits. El nmero a almacenar era mayor de 32767 (el mayor entero con signo de 16 bits) y se produjo un fallo de conversin y una excepcin.
Ejemplos de fallos
Fallo de los misiles Patriot Misiles utilizados en la guerra del golfo en 1991 para interceptar los misiles iraques Scud Fallo en la interceptacin debido a errores en el clculo del tiempo. El reloj interno del sistema proporciona dcimas de segundo que se expresan como un entero Este entero se convierte a un real de 24 bits con la perdida de precisin correspondiente. Esta prdida de precisin es la que provoca un fallo en la interceptacin
Flix Garca Carballeira Sistemas Distribuidos (2012-2013) 9
Ejemplos de fallos
Fallo en la sonda Viking enviada a Venus En lugar de escribir en Fortran DO 20 I = 1,100 que es un bucle de 100 iteraciones sobre la etiqueta 20, se escribi: DO 20 I = 1.100 y como los blancos no se tienen en cuenta el compilador lo interpret como: DO20I = 1.100 es decir, la declaracin de una variable (O20I) con valor 1.100. D indica un identificador real
Flix Garca Carballeira Sistemas Distribuidos (2012-2013) 10
Tipos de fallos
Fallos transitorios Desaparecen solos al cabo de un cierto tiempo. Ejemplo: interferencias en comunicaciones, fallos transitorios en los enlaces de comunicacin. Fallos permanentes Permanecen hasta que el componente se repara o sustituye. Ejemplo: roturas en el hardware, errores de software. Fallos intermitentes: Fallos transitorios que ocurren de vez en cuando. Ejemplo: calentamiento de un componente hardware. Objetivo: evitar que los fallos produzcan averas.
Flix Garca Carballeira Sistemas Distribuidos (2012-2013) 11
Tipos de fallos
Defecto fsico Diseo incorrecto
Permanente
Intermitente
Error
Avera
Transitorio
12
Fiabilidad
El tiempo de vida de un sistema se representa mediante una variable aleatoria X Se define la fiabilidad del sistema como una funcin R(t) R(t) = P(X > t) De forma que:
R(0) = 1 y R() = 0
Fiabilidad R() = 0 Tiempo R(0) = 1
13
Fiabilidad
A partir del estudio de los fallos de los componentes de obtiene la fiabildad
R(0) = 1 Fiabilidad
R() = 0 Tiempo
14
Ejemplos de distribuciones
Exponencial: Si la tasa de errores es constante (generalmente verdadero para componentes electrnicos), la fiabilidad sigue una exponencial.
15
Ejemplos de distribuciones
Normal: Usada para describir los equipos con una tasa de errores que se incrementa con el paso del tiempo.
16
Ejemplo de distribuciones
Normal logartmica: Se encuentra cuando los tiempos de fallo o reparacin dependen de factores que contribuyen de forma acumulativa (fatiga).
17
Ejemplo de distribuciones
Weibull:
Vida caracterstica (tiempo en el que el 63,2% de poblacin falla) y factor de forma (asociado a la tasa de error, siendo b=1 tasa de error constante).
18
Sistema serie
Sea Ri(t) la fiabilidad del componente i El sistema falla cuando algn componente falla Si los fallos son independientes entonces
R (t ) = R i (t )
i =1 N
Se cumple que:
R(t ) < Ri (t )
Sistema paralelo
donde Q i (t ) = 1 R i (t )
20
Disponibilidad
En muchos casos es ms interesantes conocer la disponibilidad Se define la disponibilidad de un sistema A(t) se define como la probabilidad de que el sistema est funcionando correctamente en el instante t La fiabilidad considera el intervalo [0,t] La disponibilidad considera un instante concreto de tiempo Un sistema se modeliza segn el siguiente diagrama de estados
Averia/caida funcioando reparado Parado (reparacin)
21
Tipos de paradas
Mantenimiento correctivo Debido a fallos Mantenimiento preventivo Para prevenir fallos Pueden planificarse
22
Medida de la disponibilidad
Sea TMF el tiempo medio hasta el fallo Sea TMR el tiempo medio de reparacin Se define la disponibilidad de un sistema como:
TMF disponibil idad = TMF + TMR
Qu significa una disponibilidad del 99%? En 365 das funciona correctamente 99*365/100 = 361.3 das Est sin servicio 3.65 das
23
24
18%
23%
Fuente: Gartner/Dataquest
25
Tolerancia a fallos Conseguir que el sistema contine funcionando aunque se produzcan fallos. Se utilizan en la etapa de funcionamiento del sistema. Es necesario saber los posibles tipos de fallos, es decir, anticiparse a los fallos.
Flix Garca Carballeira Sistemas Distribuidos (2012-2013) 26
Pruebas y depuracin
Sistema en ejecucin
Estrategia de fiabilidad
Evitacin de fallos
Prevencin de fallos
Tolerancia a fallos
27
Prevencin de fallos
Evitacin de fallos: evitar la introduccin de fallos en el desarrollo del sistema. Uso de componentes muy fiables. Especificacin rigurosa, mtodos de diseo comprobados. Empleo de tcnicas y herramientas adecuadas. Eliminacin de fallos: eliminar los fallos introducidos durante la construccin del sistema. No se puede evitar la introduccin de fallos en el sistema (errores en el diseo, programacin). Revisiones del diseo. Pruebas del sistema.
Flix Garca Carballeira Sistemas Distribuidos (2012-2013) 28
29
Tolerancia a fallos
La tolerancia a fallos se basa en la redundancia. Se utilizan componentes adicionales para detectar los fallos, enmascararlos y recuperar el comportamiento correcto del sistema. El empleo de redundancia aumenta la complejidad del sistema y puede introducir fallos adicionales si no se gestiona de forma correcta.
30
32
Deteccin de errores
Para ofrecer tolerancia a fallos es necesario en primer lugar detectar los efectos de los errores. No se puede detectar un fallo directamente. El efecto de los fallos darn lugar a errores en algn lugar del sistema. El punto de partida de cualquier tcnica de tolerancia a fallos es la deteccin de un estado errneo en el funcionamiento del sistema
33
34
Recuperacin de errores
Una vez detectado el error es necesario recuperar al sistema del error. Es necesario utilizar tcnicas que transformen el estado errneo del sistema en otro estado bien definido y libre de errores. Dos tcnicas bsicas: Recuperacin hacia atrs.Cuando se detecta un error en el sistema se vuelve a un estado anterior libre de errores.
Puntos de recuperacin o Checkpoints
Recuperacin hacia adelante. Llevar al sistema a un estado libre de errores (no volviendo hacia atrs).
Flix Garca Carballeira Sistemas Distribuidos (2012-2013) 35
Error
Ejecucin 2
36
37
Redundancia
Todas las tcnicas de tolerancia a fallos se basan en el uso de la redundancia. Redundancia esttica: Los componentes redundantes se utilizan dentro del sistema para enmascarar los efectos de los componentes con defectos. Redundancia dinmica. La redundancia se utiliza slo para la deteccin de errores. La recuperacin debe realizarla otro componente. Redundancia en el diseo. Partes de un diseo pueden ser redundantes. Redundancia temporal. Mediante el uso repetido de un componente en presencia de fallos. Adecuado para fallos transitorios.
38
Redundancia hardware
Redundancia modular triple (TMR). Ejemplo de redundancia esttica. NMR: redundancia con N componentes redundantes Para permitir F fallos se necesitan N mdulos, con N = 2F+1
C entrada C V salida
C: componente V: votador
39
40
Duplicacin y comparacin
41
42
43
Airbus A320
44
Redundancia esttica
Redundancia dinmica
46
Las tcnicas de tolerancia a fallos de SW permiten obtener una alta fiabilidad a partir de componentes de menor fiabilidad
Sistemas Distribuidos (2012-2013) 47
Redundancia en el software
Sistema fiable
Sistema no redundante
Sistema redundante
Redundancia esttica
Redundancia dinmica
48
Redundancia en el software
Tcnicas para detectar y corregir errores de diseo. Redundancia esttica Programacin con N versiones Redundancia dinmica en el software: Bloques de recuperacin Proporcionan recuperacin hacia atrs (y adelante) Programacin con N versiones autocomprobantes Excepciones Proporcionan recuperacin hacia adelante. Todos los mtodos son sensibles a los errores en los requisitos
49
Redundancia esttica
Programacin con N versiones: La programacin N-versin se define como la generacin independiente de N (N>=2) programas a partir de una misma especificacin. Los programas se ejecutan concurrentemente, con la misma entrada y sus resultados son comparados por un proceso coordinador. El resultado han de ser el mismo. Si hay discrepancia, se realiza una votacin.
versin 1 ENTRADA versin 2 versin 3
Flix Garca Carballeira Sistemas Distribuidos (2012-2013)
51
Redundancia esttica
La programacin con N versiones depende de: Una especificacin inicial correcta. Un error de especificacin aparece en todas las versiones. Un desarrollo independiente No debe haber interaccin entre equipos de desarrollo. Uso incluso de lenguajes de programacin distintos. No est claro que programadores distintos cometan errores independientes. Disponer de un presupuesto suficiente Los costes de desarrollo se multiplican. El mantenimiento tambin es ms costosa. Para N versiones no est claro si el presupuesto ser N veces el presupuesto necesario para una versin.
Flix Garca Carballeira Sistemas Distribuidos (2012-2013) 52
Redundancia dinmica
Redundancia dinmica en el software: Los componentes redundantes slo se ejecutan cuando se detecta un error. Se aplican las cuatro fases: Deteccin de errores Confinamiento y diagnostico de daos Recuperacin de errores Tratamiento de fallos y servicio continuado
1. 2. 3. 4.
53
Deteccin de errores
Por el entorno de ejecucin: Error de hardware (ej. instruccin ilegal, divisin por cero). Sistema operativo (ej: referencia a un puntero nulo). Por el software de aplicacin: Duplicacin (redundancia con dos versiones). Cdigos detectores de error. Validacin del estado del sistema. Validacin estructural.
Comprueban la integridad de objetos como listas o colas (nmero de elementos, punteros redundantes).
54
55
Recuperacin de errores
Situar el sistema en un estado correcto desde el cual se puede seguir funcionando. Etapa ms importante. Dos formas: Recuperacin hacia adelante:
Se avanza desde un estado errneo haciendo correcciones sobre partes del estado.
56
57
Ejecucin 2
Datos activos Datos de recuperacin
Vuelta atrs
Dispositivo de recuperacin
58
Conceptos
Punto de recuperacin (checkpoint): instante en el que se salvaguarda el estado del sistema. Datos de recuperacin: datos que se salvaguardan. Registros de la mquina. Datos modificados por el proceso (variables globales y pila). Pginas del proceso modificadas desde el ltimo punto de recuperacin. Datos activos: conjunto de datos a los que accede el sistema despus de establecer un punto de recuperacin. Vuelta atrs: proceso por el cual los datos salvaguardados se restauran para restablecer el estado. Regin de recuperacin: periodo de tiempo en el que los datos de recuperacin de un punto de recuperacin estn activos y se pueden restaurar en caso de detectarse un fallo.
Flix Garca Carballeira Sistemas Distribuidos (2012-2013) 59
Tipos de sistemas
Transparentes a la aplicacin: El establecimiento de los puntos de recuperacin y la vuelta atrs queda bajo el control del HW o del sistema operativo. Ventaja: transparencia. Las aplicaciones pueden transportarse sin problemas. Inconveniente: pueden establecerse puntos de recuperacin en momentos que no son necesarios (posibles sobrecargas). Controlados por la aplicacin: El diseador de la aplicacin establece los puntos de recuperacin. Momento adecuado. Permite minimizar el conjunto de datos a salvaguardar. Problema: falta de transparencia.
60
Primitivas necesarias
Establecer punto de recuperacin: Salvaguarda los registros y las pginas modificadas por el proceso desde el ltimo punto de recuperacin. Anular punto de recuperacin: Se anulan los datos correspondientes a un punto de recuperacin y se libera el espacio ocupado por stos en el dispositivo de recuperacin. Restaurar punto de recuperacin: Se copian los datos salvaguardados en el dispositivo de recuperacin sobre las copias activas.
61
62
Efecto domin
Se produce un conjunto de vuelta atrs no acotado que puede llegar a reiniciar el sistema concurrente. Solucin: lneas de recuperacin Objetivo: acotar el efecto domin en caso de realizar una vuelta atrs encontrando un conjunto de procesos y de puntos de recuperacin que permita hacer volver al sistema a un estado consistente.
R11 P1 IPC1 P2 R21 R22 IPC2 IPC3 IPC4 R12 R13
63
64
Bloques de recuperacin
Tcnica de recuperacin hacia atrs. Un bloque de recuperacin es un bloque tal que: Su entrada es un punto de recuperacin. A su salida se realiza una prueba de aceptacin Sirve para comprobar si el mdulo primario del bloque termina en un estado correcto. Si la prueba de aceptacin falla Se restaura el estado inicial en el punto de recuperacin. Se ejecuta un mdulo alternativo del mismo bloque. Si vuelve a fallar, se intenta con otras alternativas. Cuando no quedan mdulos alternativos el bloque falla y la recuperacin debe realizarse en un nivel ms alto.
65
Esquema de recuperacin
Restaurar el bloque de recuperacin Falla Entrada al bloque de recuperacin Salida del bloque de recuperacin
Si
Prueba aceptacin
Pasa
66
Puede haber bloques anidados Si falla el bloque interior, se restaura el punto de recuperacin del bloque exterior.
Flix Garca Carballeira Sistemas Distribuidos (2012-2013) 67
Prueba de aceptacin
La prueba de aceptacin proporciona el mecanismo de deteccin de errores que activa la redundancia en el sistema. El diseo de la prueba de aceptacin es crucial para el buen funcionamiento de los bloques de recuperacin. Hay que buscar un compromiso entre deteccin exhaustiva de fallos y eficiencia de ejecucin. No es necesario que todos los mdulos produzcan el mismo resultado sino resultados aceptables. Los mdulos alternativos pueden ser ms simples aunque el resultado sea peor para evitar que contengan errores. Sobrecarga en aplicaciones de tiempo real
Flix Garca Carballeira Sistemas Distribuidos (2012-2013) 68
FCC1
S P O I L E R S
70
Excepciones
Una excepcin es una manifestacin de un cierto tipo de error. Cuando se produce un error en el sistema se genera (eleva) la excepcin correspondiente en el contexto donde se ha invocado la actividad que ha dado lugar al error. De esta forma se puede manejar la excepcin en este contexto. Es un mecanismo de recuperacin de errores hacia adelante. Tambin se puede utilizar para realizar recuperaciones hacia atrs.
71
04
e05
P1 e11
Flix Garca Carballeira Sistemas Distribuidos (2012-2013)
e12
e13
74
1. 2. 3.
C es un conjunto de estados describe las posibles transiciones( C C) I describe los estados iniciales(I C)
75
Configuraciones y estados
En el sistema de transicin de estados del sistema distribuido Los estados se denominan configuraciones Las transiciones se denominan transiciones de configuracin En el sistema de transicin de estados de cada proceso Los estados se denominan estados Las transiciones se denominan eventos Una ejecucin en un sistema distribuido es una secuencia de configuraciones (1, 2, 3, ) donde: 1 es una configuracin inicial, Hay una transicin entre ii+1 para todo i 1 La secuencia puede ser finita o infinita
76
77
Algoritmos locales
Algoritmo local:
Un proceso cambia de un estado a otro (evento inerno) Un proceso cambia de un estado a otro y enva un mensaje a otro proceso (evento de envo) Un proceso recibe un mensaje y cambia su estado (evento de recepcin)
Restricciones Un proceso p solo puede recibir un mensaje despus de haber sido enviado por otro Un proceso p solo puede cambiar del estado c al estado d si est actualmente en el estado c
78
Detectores de fallos
pi
pj
79
Detectores de fallos
Proceso pj falla pj X
pi
80
Detectores de fallos
Proceso pj falla pj X
pi
81
pi
ping ack
pj
82
pi
heartbeat
pj
- pj mantiene un nmero de secuencia - pj enva a pi a latido con un n de sec. - incrementado cada T unidades de t.
83
85
Replicacin
Objetivos Mejorar el rendimiento (cach) Mejorar la disponibilidad Si p es la probabilidad de fallo de un servidor Con n servidores la probabilidad de fallo del sistema ser pn Tipos de replicacin De datos De procesos Problemas que introduce Consistencia Requisitos Transparencia Consistencia Rendimiento
Flix Garca Carballeira Sistemas Distribuidos (2012-2013) 86
FE
RM
RM
Gestores de Rplicas
FE
RM
87
Mtodos de replicacin
Mtodos pesimistas: mtodos de replicacin que aseguran consistencia: mtodos pesimistas, en caso de fallos en la red imponen limitaciones en el acceso a los datos Copia primaria Rplicas activas Esquemas de votacin
Estticos Dinmicos
Mtodos optimistas: mtodos que no aseguran una consistencia estricta: no imponen limitaciones El sistema de ficheros CODA
Flix Garca Carballeira Sistemas Distribuidos (2012-2013) 88
Modelos de consistencia
Consistencia fuerte: Utilizan esquemas de replicacin pesimistas. Mantienen una consistencia total dentro del grupo de rplicas. Consistencia dbil: Utilizan esquemas de control de concurrencia optimistas Permite actualizaciones locales sin ningn tipo de restricciones En algn momento se comprueba la consistencia de cada rplica y aquellas modificaciones que hallan dado lugar a inconsistencias tienen que anularse o corregirse. Vlidas cuando hay pocos accesos concurrentes en escritura.
89
Copia primaria
Para hacer frente a k fallos, se necesitan k+1 copias Un nodo primario K nodos de respaldo Lecturas: se envan al primario Escrituras: se envan al primario El primario realiza la actualizacin y guarda el resultado El primario actualiza el resto de copias El primario responde al cliente Cuando falla el primario un nodo secundario toma su papel Otras alternativas Las copias se actualizan en segundo plano
Flix Garca Carballeira Sistemas Distribuidos (2012-2013) 90
Sincronizacin de rplicas
91
Rplicas activas
Todas los nodos sirven peticiones Mejor rendimiento en lecturas En escrituras se utiliza un multicast atmico Se asegura el orden de las escrituras
RM C FE RM RM FE C
92
93
Cmo elegir W y R?
Se analizan dos factores: Rendimiento: depende del % de lecturas y escrituras y su coste Tolerancia a fallos: depende de la probabilidad con la que ocurren los fallos Ejemplo: N=7 Coste de W = 2 veces el coste de R Porcentaje de lecturas = 70% Probabilidad de fallo = 0.05
94
Mtodo de votacin
READ Se lee de R rplicas, se queda con la copia con la ltima versin WRITE Hay que asegurarse que todas las rplicas se comportan como una sla (seriabilidad) Se realiza en primer lugar una operacin READ para determinar el nmero de versin actual. Se calcula el nuevo nmero de versin. Se inicia un 2PC para actualizar el valor y el n de versin en W o ms rplicas.
Flix Garca Carballeira Sistemas Distribuidos (2012-2013) 95
Two-phase commit
Two-phase-commit (2PC) Denominamos coordinador al proceso que realiza la operacin
Coordinador: multicast: ok to commit? recoger las respuestas todos ok => send(commit) else => send(abort) Procesos: ok to commit=> guardar la peticin en un rea temporal y responder ok commit => hacer los cambios permanentes abort => borrar los datos temporales
P0 P1
OK to commit
P2
Commit!
96
Votacin jerrquica
El problema del mtodo anterior es que w aumenta con el n de rplicas Solucin: quorum jerrquico Ej: nmero de rplicas = 5 x 5 = 25 (nodos hoja)
0
1 2
97
Votacin jerrquica
Se realiza el quorum por niveles R1 1 1 1 2 2 3 W1 5 5 5 4 4 3 R2 1 2 3 2 3 3 W2 5 4 3 4 3 3 RT 1 2 3 4 6 9 WT 25 20 15 16 12 9
Cul se elige?
Flix Garca Carballeira Sistemas Distribuidos (2012-2013) 98
100
101
Algoritmo de escritura
i accesible solicita NVi y SCi M = max{NVi} incluido l I = {i tal que VNi = M} N = max{SCi, i I} if I N/2 then el nodo no pertenece a una particin mayoritaria, se rechaza la operacin else { nodos I Actualizar VNi = M+1 SCi = I }
102
Ejemplo
N= 5 Inicialmente: A VN SC 9 5 B 9 5 C 9 5 D 9 5 E 9 5
B 9 5
C 9 5
D 9 5
E 9 5
Particin 2
103
Ejemplo
Escritura en particin 2? M= max{9, 9} = 9 I={D, E} N= 5 , I = 2 5/2 No se puede realizar Escritura en particin 1? M= max{9, 9, 9} = 9 I={A, B, C} N=5 I = 3 > 5/2 Se puede actualizar A VN SC
Flix Garca Carballeira
B 10 3
C 10 3
D 9 5
E 9 5
104
10 3
Ejemplo
Nueva particin A VN SC 10 3
Particin 1
B 10 3
C 10 3
Particin 2
D 9 5
E 9 5
Particin 3
Ejemplo
A VN SC 11 2
Particin 1
B 11 2
C 10 3
D 9 5
E 9 5
Particin 3
Particin 2
106
Ejemplo
Se une la particin 2 y 3
A VN SC 11 2
Particin 1
B 11 2
C 10 3
D 9 5
E 9 5
Particin 2
Ejemplo
Se une la particin 1 y 2
A VN SC 11 2
Particin 1
B 11 2
C 10 3
D 9 5
E 9 5
Particin 2
Ejemplo
A VN SC 12 3
Particin 1
B 12 3
C 12 3
D 9 5
E 9 5
Particin 2
109
112
Ejemplo
Tres servidores = {A, B, C} Inicialmente V = (0,0,0) en los tres Cuando se realiza una actualizacin: V=(1,1,1) en los tres Se produce un fallo de red: Grupo 1: {A,B} Grupo 2: {C} Se produce una actualizacin sobre el grupo 1 V=(2,2,1) para el grupo 1 Se produce un fallo de red: Grupo 1: {A}, V=(2,2,1) Grupo 2: {B, C} (2,2,1) (1,1,1) se actualiza la copia de C y V = (2,2,2) en B y C
113
Ejemplo
Se produce una actualizacin sobre el grupo 2 V=(2,3,2) en {B,C} Situacin 1: se une {A} a {B,C} (2,2,1) (2,3,3) se actualiza la copia de {A} y V =(3,3,3) Situacin 2: Se modifica la versin de {A} en A, V= (3,2,1) Se une A con V=(3,2,1) a {B,C} con V=(2,3,2) Se comparan (3,2,1) y (2,3,2), ninguno domina conflicto
114
Problema de la replicacin
Consistencia Para formalizar la nocin de consistencia, comenzaremos formalizando las nociones de tiempo
115
Ordenacin de eventos
Monitorizacin del comportamiento de una aplicacin distribuida Ejemplo: El observador debe ordenar los eventos de recepcin de mensajes en los procesos P1 y P2
P2 Observador
e1
e2
e3
e4
e5
116
Ejemplo
Monitorizacin del comportamiento de una aplicacin distribuida El observador debe ordenar los eventos de recepcin de mensajes en los procesos P1 y P2
P2 Observador
e1
e2
e3
e4
e5
Para ordenar eventos podemos asignarles marcas de tiempo ei ek MT(ei) < MT (ek )
117
P1
m1 m2
P2 Observador
e2
e1
?
Flix Garca Carballeira Sistemas Distribuidos (2012-2013) 118
P1 P2 Observador
1 m1 6 m2
e1-6
e2-3
?
Flix Garca Carballeira Sistemas Distribuidos (2012-2013) 119
P1 P2 Observador
1 m1 6 m2
e1-6
e2-3
120
Relojes fsicos
Para ordenar dos eventos de un proceso basta con asignarles una marca de tiempo Para un instante fsico t Hi(t): valor del reloj HW (oscilador) Ci(t): valor del reloj SW (generado por el SO)
Ci(t) = a Hi(t) + b
Ej: # ms o ns transcurridos desde una fecha de referencia
Dos relojes en dos computadores diferentes dan medidas distintas Necesidad de sincronizar relojes fsicos de un sistema distribuido
Flix Garca Carballeira Sistemas Distribuidos (2012-2013) 121
122
Relojes lgicos
Dado que no se pueden sincronizar perfectamente los relojes fsicos en un sistema distribuido, no se pueden utilizar relojes fsicos para ordenar eventos Podemos ordenar los eventos de otra forma?
P1
m1 m2 m3 m4 m5
P2 Observador
e1
e2
e3
e4
e5
123
Causalidad potencial
En ausencia de un reloj global la relacin causa-efecto (precede a) es la nica posibilidad de ordenar eventos Relacin de causalidad potencial (Lamport) eij = evento j en el proceso i Si j < k entonces eij eik Si ei=send(m) y ej=receive(m), entonces ei ej La relacin es transitiva Dos eventos son concurrentes (a || b) si no se puede deducir entre ellos una relacin de causalidad potencial
124
125
126
Ejemplo
p1
0 1 2 3 4
p2
0 4 5
p3
0 1 tiempo 6
127
Se necesita una relacin (F(e), <) tal que: a H b si y slo si F(a) < F(b) Los relojes vectoriales permiten representar de forma precisa la relacin de causalidad potencial
129
C(e11) < C(e22), y e11e22 es cierto C(e11) < C(e32), pero e11 e32 es falso
Flix Garca Carballeira Sistemas Distribuidos (2012-2013) 130
Relojes vectoriales
Desarrollado independientemente por Fidge, Mattern y Schmuck Todo proceso lleva asociado un vector de enteros RV RVi[a] es el valor del reloj vectorial del proceso i cuando ejecuta el evento a. Mantenimiento de los relojes vectoriales Inicialmente RVi= 0 i Cuando un proceso i genera un evento RVi[i ] = RVi[i ] +1 Todos los mensajes llevan el RV del envo Cuando un proceso j recibe un mensaje con RV RVj = max(RVj , RV ) (componente a componente) RVj[j ] = RVj[j ] +1 (evento de recepcin)
131
Ejemplo
p1
[1,0,0] [2,0,0] [3,0,0] [4,0,0] [5,0,0]
p2
[0,1,0] [4,2,0] [4,3,0]
p3
[0,0,1] [0,0,2] [4,3,3]
tiempo
132
133
Utilidad
p1
[1,0,0] [2,0,0] [3,0,0] [4,0,0] [5,0,0]
p2
[0,1,0] [5,2,0] [5,3,0]
p3
[0,0,1] [5,0,2] [5,0,3]
time
p2 analiza dos mensajes que recibe: de p1 [4,0,0] y de p2 [5,0,3] y puede deducir que el de p1 es anterior [4,0,0] [5,0,3]
134
Comunicacin multicast
Las primitivas de comunicacin bsicas soportan la comunicacin uno a uno. Broadcast: el emisor enva un mensaje a todos los nodos del sistema. Multicast: el emisor enva un mensaje a un subconjunto de todos los nodos. Estas operaciones se emplean normalmente mediante operaciones punto a punto.
135
Utilidad
Servidores replicados: un servicio replicado consta de un grupo de servidores. Las peticiones de los clientes se envan a todos los miembros del grupo. Aunque algn miembro del grupo falle la operacin se realizar. Mejor rendimiento: Replicando datos. Cuando se cambia un dato, el nuevo valor se enva a todos los procesos que gestionan las rplicas.
136
Tipos de multicast
Multicast no fiable: no hay garanta de que el mensaje se entregue a todos los nodos. Multicast fiable: el mensaje es recibido por todos los nodos en funcionamiento. Multicast atmico: el protocolo asegura que todos los miembros del grupo recibirn los mensajes de diferentes nodos en el mismo orden. Multicast causal: asegura que los mensaje se entregan de acuerdo con las relaciones de causalidad.
137
138
139
Multicast fiable
Se enva un mensaje a todos los procesos y se espera confirmacin de todos. Si todos confirman el multicast se ha completado. Si alguno no confirma se retransmite. Si no enva confirmacin se puede asumir que el proceso ha fallado y se elimina del grupo. Si el emisor falla durante el proceso la operacin no ser atmica. Para que la operacin sea atmica, si el emisor falla alguno de los receptores debe completar el envo a todos los dems. Cuando un proceso recibe un mensaje enva una confirmacin y monitoriza al emisor para ver si falla. Si falla completa el multicast.
140
P1 A A
P2
P3 B
P4
Tiempo B
141
tiempo c1 c2 c3
FE1
GR1
GR2
GR3
FE2
143
Implementacin
Una peticin recibida no se entrega hasta que las restricciones de ordenacin se puedan cumplir. Un mensaje estable pasa a la cola de entrega Debe asegurarse Seguridad: ningn mensaje fuera de orden Progreso: todos los mensajes se entregan
entrega
cola de espera
cola de entrega
Peticiones
144
Entrega causal
Understanding the limitations of causally and totally ordered communication David R. Cheriton , Dale Skeen ACM SIGOPS Operating Systems Review Volume 27 , Issue 5 (December 1993) Pages: 44 - 57 PDF
145
Problemas de consenso
Objetivo: que un conjunto de procesos se pongan de acuerdo en una determinada accin o valor. Problema de los generales bizantinos: Sistema distribuido compuesto por una serie de nodos (generales) que intercambian informacin entre ellos. Los componentes pueden exhibir fallos bizantinos (generales traidores)
Un nodo con fallo puede enviar informacin diferente a diferentes nodos (para un mismo dato).
Objetivo: que los nodos sin fallo alcancen un acuerdo o consenso sobre un determinado valor (ataque, retirada, espera). Es decir que vean el mismo valor para un dato.
Flix Garca Carballeira Sistemas Distribuidos (2012-2013) 146
Problema de consenso
En un sistema sncrono es posible En un sistema asncrono es imposible Impossibility of distributed consensus with one faulty process Michael J. Fischer, Nancy A. Lynch, Michael S. Paterson Journal of the ACM (JACM) Volume 32 , Issue 2 (April 1985) , Pages: 374 382 PDF Detector de fallos: subsistema responsable de detectar fallos en los nodos
147
Por qu?
En un sistema sncrono: el uso de timouts puede determinar si un proceso ha fallado o no Detector de fallo perfecto En un sistema asncrono: no se puede determinar si un proceso ha fallado o no (puede ejecutar ms lento o sus mensajes pueden retrasarse) No existe un detector de fallos
148