Clase 2

Diseo de Sistemas Distribuidos
Mster en Ciencia y Tecnologa Informtica
Curso 2012-2013
Tolerancia a fallos
Flix Garca Carballeira Grupo de Arquitectura de Computadores felix.garcia@uc3m.es
Contenido
Conceptos bsicos sobre fiabilidad y tolerancia a fallos Tolerancia a fallos del software Replicacin Consistencia Multicast
Flix Garca Carballeira
Sistemas Distribuidos (2012-2013)
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
Origen de los fallos

Fallos hardware Fallos permanentes o transitorios en los componentes hardware. Fallos permanentes o transitorios en los subsistemas de comunicacin. Fallos software Especificacin inadecuada. Fallos introducidos por errores en el diseo y programacin de componentes software.
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
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
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.
Tipos de fallos
Defecto fsico Diseo incorrecto
Permanente
HW inestable Entorno inestable Error del operador
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 )
La fiabilidad del sistema es menor

Sistema paralelo
El sistema falla cuando fallan todos los componentes

R (t ) = 1 Q i (t )
i =1 N
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
Tiempo anual sin servicio

Disponibilidad (%) 98% 99% 99.8% 99.9% 99.99% 99.999% 99.9999% Das sin servicio al ao 7.3 das 3.65 das 17 horas, 30 minutos 8 horas, 45 minutos 52 minutos, 30 segundos 5 minutos, 15 segundos 31.5 segundos
24
Causas de deteccin no planificadas

SW bsico HW Errores humanos Problemas en transmisin Desastre natural Desconocido 8% 17% 7% 27%
18%
23%
Fuente: Gartner/Dataquest
25
Tcnicas para aumentar la fiabilidad

Prevencin de fallos Evitar que se introduzcan fallos en el sistema antes que entre en funcionamiento. Se utilizan en la fase de desarrollo del sistema.
Evitar fallos. Eliminar fallos.
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.
Tcnicas para obtener fiabilidad
Fases en el ciclo de vida
Especificacin, diseo e implementacin
Pruebas y depuracin
Sistema en ejecucin
Estrategia de fiabilidad
Evitacin de fallos
tiempo Eliminacin 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.
Limitaciones de la prevencin de fallos

Los componentes hardware se deterioran y fallan. La sustitucin de componentes no siempre es posible: No se puede detener el sistema. No se puede acceder al sistema. Deficiencias en las pruebas No pueden ser nunca exhaustivas. Slo sirven para mostrar que hay errores, pero no permiten demostrar que no los hay. A veces es imposible reproducir las condiciones reales de funcionamiento del sistema. Los errores de especificacin no se detectan. Solucin: utilizar tcnicas de tolerancia a fallos.
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
Grados de tolerancia a fallos

Tolerancia completa: el sistema contina funcionando, al menos durante un tiempo, sin prdida de funcionalidad ni de prestaciones. Degradacin aceptable: el sistema sigue funcionando en presencia de errores pero con una prdida de funcionalidad o de prestaciones hasta que se repare el fallo. Parada segura: el sistema se detiene en un estado que asegura la integridad del entorno hasta que el fallo sea reparado. Trenes Airbus A320 El nivel de tolerancia a fallos depende de cada aplicacin.
Fases en la tolerancia a fallos

Deteccin de errores Confinamiento y diagnostico de daos Recuperacin de errores Tratamiento de fallos y servicio continuado Estas cuatro fases constituyen la base de todas las tcnicas de tolerancia a fallos y deberan estar presentes en el diseo e implementacin de un sistema tolerante a fallos.
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
Confinamiento y diagnstico de fallos

Cuando se detecta un error en el sistema, ste puede haber pasado por un cierto nmero de estados errneos antes. Puede haber un cierto retraso entre la manifestacin de un fallo y su deteccin. El fallo puede haber provocado errores en otras partes del sistema. Antes de hacer frente al error detectado es necesario: Valorar el alcance de todos los fallos que pueden haberse generado. Limitar la propagacin de errores mediante el confinamiento de los daos.
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).
Recuperacin hacia atrs

Vuelta atrs
Punto de recuperacin Ejecucin 1
Error
Ejecucin 2
36
Tratamiento de fallos y servicio continuado

Una vez que el sistema se encuentra libre de errores es necesario que siga ofreciendo el servicio demandado. Una vez detectado un error: Se repara el fallo. Se reconfigura el sistema para evitar que el fallo pueda volver a generar errores. Cuando los errores fueron transitorios no es necesario realizar ninguna accin.
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
Fiabilidad de un sistema TMR

Fiabilidad de un sistema TMR es:
RTMR = Rm + 3 Rm (1 R m ) = 3 Rm 2 Rm
3 2 2 3
Donde Rm es la fiabilidad de un componente RTMR < Rm si Rm < 0.5

Cuando la fiabilidad del componente es muy baja la redundancia no mejora la fiabilidad
Para Rm = 0.9, RTMR = 0.972
40
Duplicacin y comparacin
41
Votadores y detectores de fallos
42
Arquitectura de un FCC (Boeing 777)
43
Airbus A320
44
Diseo de sistemas tolerantes a fallos

Para disear un sistema tolerante a fallos sera ideal identificar todos los posibles fallos y evaluar las tcnicas adecuadas de tolerancia a fallos. Sin embargo: Hay fallos que se pueden anticipar (fallos en el HW). Hay fallos que no se pueden anticipar (fallos en el SW). Objetivo: Minimizar la redundancia. Cuanto mayor es la redundancia mayor complejidad tiene el sistema estando ms propenso a errores. Necesario gestionar adecuadamente la redundancia. Maximizar la fiabilidad del sistema. Los errores surgen por: Fallos en los componentes. Fallos en el diseo.
Estrategias para disear un sistema fiable Sistema

fiable Sistema no redundante Sistema redundante
Sistemas Tolerantes a fallos
Evitacin / prevencin de fallos
deteccin de Errores (reinicio)
Redundancia esttica
Redundancia dinmica
46
Tolerancia a fallos de software

Los fallos en el software se deben a fallos en el diseo. Funciones tpicas de fallos aplicadas al software.
Probabilidad de fallo Tiempo
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
Probabilidad de fallo Tiempo
Redundancia en el software
Sistema fiable
Sistema no redundante
Sistema redundante
Sistemas Tolerantes a fallos
Evitacin / prevencin de fallos
deteccin de Errores (reinicio)
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)
SALIDA votacin Avera (no mayora)

50
Tolerancia a fallos con N versiones

Deteccin de errores: La realiza el programa votador. Confinamiento y diagnostico de daos: No es necesaria ya que las versiones son independientes. Recuperacin de errores: Se consigue descartando los resultados errneos. Tratamiento de fallos y servicio continuado: Se consigue ignorando el resultado de la versin errnea. Si todas las versiones producen valores diferentes se detecta el error pero no se ofrece recuperacin.
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.
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
Confinamiento y diagnstico de daos

Importante confinar los daos provocados por un fallo a una parte limitada del sistema. Para ello se estructura el sistema de forma que se minimice el dao causado por los componentes defectuosos. Tcnicas: Descomposicin modular: confinamiento esttico. Acciones atmicas: confinamiento dinmico.
Mueven al sistema de un estado consistente a otro estado consistente.
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.
Recuperacin hacia atrs:

Se retrocede a un estado anterior correcto que se ha guardado previamente.
56
Recuperacin hacia adelante

Toma como punto de partida los datos errneos que sometidos a determinadas transformaciones permiten alcanzar un estado libre de errores. Depende de una prediccin correcta de los posibles fallos y de su situacin. Ejemplos: Cdigos autocorrectores que emplean bits de redundancia.
57
Recuperacin hacia atrs

Punto de recuperacin Vuelta atrs Error Ejecucin 1 Regin de recuperacin
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.
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
Puntos de recuperacin en sistemas concurrentes

Tipos de procesos concurrentes: Independientes: la ejecucin de un proceso no afecta a los otros.
La recuperacin se realiza como se ha descrito hasta ahora.
Competitivos: los procesos comparten recursos del sistema.

No comparten datos y se tratan como los procesos independientes.
Cooperantes (dependientes): cooperan e intercambian informacin entre ellos.

Una vuelta atrs en un proceso puede provocar estados inconsistentes en otros.
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
Tcnicas de redundancia dinmica en el software

Bloques de recuperacin Programacin con N versiones autocomprobantes Excepciones
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
Establecer punto de recuperacin
Quedan alternativas? No El bloque de recuperacion falla
Si
Ejecutar proxima alternativa
Prueba aceptacin
Pasa
Descartar punto de recuperacin
66
Posible sintaxis para bloques de recuperacin

ensure < condicin de aceptacin > by < mdulo primario > else by < mdulo alternativo 1 > else by < mdulo alternativo 2 > ... else by < mdulo alternativo N > else error;
Puede haber bloques anidados Si falla el bloque interior, se restaura el punto de recuperacin del bloque exterior.
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
Programacin con N versiones autocomprobantes

Similar a la programacin con N versiones pero con redundancia dinmica. Se basa en la diversidad de diseo. Cada componente realiza su propia comprobacin. Dos tipos de componentes autocomprobantes: Una variante y una prueba de aceptacin. Dos variantes y un algoritmo de comparacin. La tolerancia a fallos se consigue por medio de la ejecucin paralela de al menos dos componentes: Uno es el activo. Otros de reserva. Ejemplo: El Airbus A-320 utiliza un sistema basado en dos componentes autocomprobantes cada uno basado en la ejecucin paralela de dos variantes cuyos resultados se comparan.
Ejemplo. Airbus A320

Requisito: probabilidad mxima de fallo por hora de vuelo: 10-10 Utiliza un sistema basado en dos componentes autocomprobantes cada uno basado en la ejecucin paralela de dos variantes cuyos resultados se comparan
EFCU1
FCC1
COM MON COM MON

FCC2 ORDENES PILOTO
COM MON ALERONES COM MON

EFCU2
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
Manejo de excepciones. Ejemplo

Las excepciones se manejan dentro de un bloque try-catch.
try { // instrucciones; } cath (exception E) { // manejador para el tipo de excepcin E } catch (exception F) { // manejador para el tipo de excepcin F } catch (...) { // excepcin desconocida. Se puede elevar throw; }
Modelos de sistemas distribuidos

Modelo sncrono Relojes sincronizados Entrega de mensajes acotada Tiempo de ejecucin de procesos acotado Modelo asncrono No hay sincronizacin de relojes Entrega de mensajes no acotada Tiempo de ejecucin de procesos totalmente arbitraria Sistemas parcialmente sncronos Tiempos acotados pero desconocidos
Modelo de sistema distribuido

Modelo de sistema: Procesos secuenciales {P1, P2, ...Pn} que ejecutan un algoritmo local Canales de comunicacin Eventos en Pi Ei = {ei1, ei2, ...ein} Tipos de eventos locales Internos (cambios en el estado de un proceso) Comunicacin (envo, recepcin) e e e e P0 Diagramas espacio-tiempo
01 02 03
04
e05
P1 e11
Flix Garca Carballeira Sistemas Distribuidos (2012-2013)
e12
e13
74
Sistema distribuido como un sistema de transicin de estados

Un sistema distribuido se puede modelar como un sistema de transicin de estados STE (C, , I)
1. 2. 3.
C es un conjunto de estados describe las posibles transiciones( C C) I describe los estados iniciales(I C)
El estado de un sistema distribuido, C, se puede describir como

La configuracin actual de cada proceso/procesador Los mensajes en trnsito por la red
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
Transiciones y paso de mensajes

Paso de mensajes sncrono
El envo y la recepcin de un mensaje m, ocurren en la misma transicin
Paso de mensajes asncrono

El envo de un mensaje m y su recepcin ocurren en transiciones diferentes
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
Proceso pj falla pj X
pi
80
Proceso pj falla pj X
pi
Pi es un proceso sin fallo que necesita conocer el estado de pj
81
Protocolo basada en ping
pi
ping ack
pj
De forma peridica pi interroga a pj
82
Protocolo basado en latido
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
Propiedades de los detectores de fallo

Completitud: cada proceso con fallo es detectado en algn momento. Precisin: cada fallo detectado se corresponde a un proceso con fallo Se pueden garantizar los dos en un sistema distribuido sncrono No se pueden garantizar simultneamente en un sistema distribuido asncrono Prdidas de mensajes Retardos no acotados en el envo de mensajes En un sistema asncrono, los retardos/prdidas de mensajes no se pueden distinguir del fallo de un proceso
Propiedades de los detectores anteriores

En un sistema sncrono los detectores anteriores siempre son correctos Si un proceso pj falla, entonces pi detectar el fallo siempre que pi est vivo En sistemas asncronos los detectores anteriores son completos pero no precisos
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
Arquitectura bsica de replicacin

Servicio replicado
FE
RM
RM
Gestores de Rplicas
FE
RM
Front-end: gestiona la replicacin hacindola transparente
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
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
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
Mtodo de votacin (quorum)

Se definen dos operaciones READ y WRITE Hay un conjunto de nodos N, que sirven peticiones Un READ debe realizarse sobre R copias Un WRITE debe realizarse sobre W copias Cada rplica tiene un nmero de versin V Debe cumplirse que:
R+W>N W+W>N
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.
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
Grabar en rea temporal ok
Commit!
Hacer los cambios permanentes
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?
Mtodos adaptativos dinmicos

Los mtodos anteriores (estticos) no se adaptan a los cambios que ocurren cuando hay fallos Ejemplo: Dado un esquema de votacin para 4 rplicas con
R=2 y W=3
Si se produce una particin
No se pueden realizar escrituras

Mtodo de votacin dinmica

Cada dato d est soportado por N rplicas {d1..dn} Cada dato di en el nodo i tiene un nmero de versin VNi (inicialmente 0) Se denomina actual NVA(d) = max{VNi} i Una rplica di es actual si VNi = VNA Un grupo constituye una particin mayoritaria si contiene una mayora de copias actuales de d Cada copia di tiene asociado un n entero denominado cardinalidad de actualizaciones SCi = n de nodos que participaron en la actualizacin
100
Mtodo de votacin dinmica

Inicialmente SCi = N Cuando se actualiza di SCi = n de copias de d modificadas durante esta actualizacin Un nodo puede realizar una actualizacin si pertenece a una particin mayoritaria
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
Ocurre una particin: A VN SC 9 5

Particin 1
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
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
Escritura en particin 1? N=max{10,10} = 10 I = {A, B} N= 3 I = 2 > 3/2 Se puede actualizar

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
Escritura en particin 2? M= max{10, 9, 9} = 10 I={C} N=3 I = 1 3/2 se rechaza

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
Escritura en particin 1? M= max{10, 9, 9} = 11 I={A,B} N=2 I = 1 2/2 Se actualiza

Ejemplo
A VN SC 12 3
Particin 1
B 12 3
C 12 3
D 9 5
E 9 5
Particin 2
109
Unin de un nodo a un grupo

Cuando un nodo se une a un grupo tiene que actualizar su estado:
M=max{VNi} I = {Aj, tal que M = VNj} N = max{SCk, k I} if I N/2 then no se puede unir else { Actualiza su estado VNi = M SCi = N +1 }
Replicacin del sistema de ficheros CODA

Mtodo de replicacin optimista Cada rplica lleva asociado un vector de versiones V con n componentes = grado de replicacin En el nodo j , V[j] representa el nmero de actualizaciones realizadas en la rplica de j Cuando no hay fallos de red todos los vectores son iguales en todas las rplicas Cuando hay fallos de red los vectores difieren Dados V1 y V2, V1 domina a V2 si V1(i) V2(i) i Si V1 domina a V2 hay ms actualizaciones en la copia con V1 V1 y V2 estn en conflicto si ninguno domina al otro
Replicacin del sistema de ficheros CODA

Cuando dos grupos se juntan Se comparan los vectores Si el vector de un grupo domina al vector del otro se copia la copia del primero en el segundo Si hay conflictos el archivo se marca como inoperable y se informa al propietario para que resuelva el conflicto.
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
e1, e2, e3, e4, e5

P1
m1 m2 m3 m4 m5
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
e1, e2, e3, e4, e5

P1
m1 m2 m3 m4 m5
P2 Observador
e1
e2
e3
e4
e5
Para ordenar eventos podemos asignarles marcas de tiempo ei ek MT(ei) < MT (ek )
117
Marcas de tiempo en el observador?
P1
m1 m2
P2 Observador
e2
e1
?
Marcas de tiempo en de los procesos?
P1 P2 Observador
1 m1 6 m2
e1-6
e2-3
?
Marcas de tiempo en de los procesos?
P1 P2 Observador
1 m1 6 m2
e1-6
e2-3
Los relojes deben estar sincronizados
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
Resolucin del reloj: periodo entre actualizaciones de Ci(t)

Determina la ordenacin de eventos
Dos relojes en dos computadores diferentes dan medidas distintas Necesidad de sincronizar relojes fsicos de un sistema distribuido
Sincronizacin de relojes fsicos

D: Cota mxima de sincronizacin S: fuente del tiempo UTC, t Sincronizacin externa: Los relojes estn sincronizados si |S(t) - Ci(t)| < D Los relojes se consideran sincronizados dentro de D Sincronizacin interna entre los relojes de los computadores de un sistema distribuido Los relojes estn sincronizados si |Ci(t) - Cj(t)| < D Dados dos eventos de dos computadores se puede establecer su orden en funcin de sus relojes si estn sincronizados Sincronizacin externa sincronizacin interna
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
Importancia de la causalidad potencial

Sincronizacin de relojes lgicos Depuracin distribuida Registro de estados globales Monitorizacin Entrega causal Actualizacin de rplicas
125
Relojes lgicos (algoritmo de Lamport)

Algoritmo de Lamport (1978) Cada proceso P mantiene una variable entera RLp (reloj lgico) Cuando un proceso P genera un evento, RLp=RLp+1 Cuando un proceso enva un mensaje m a otro le aade el valor de su reloj Cuando un proceso Q recibe un mensaje m con un valor de tiempo t, el proceso actualiza su reloj, RLq=max(RLq,t) +1 El algoritmo asegura que si a H b entonces RL(a) < RL(b)
126
Ejemplo
p1
0 1 2 3 4
p2
0 4 5
p3
0 1 tiempo 6
127
Relojes lgicos totalmente ordenados

Los relojes lgicos de Lamport imponen slo una relacin de orden parcial: Eventos de distintos procesos pueden tener asociado una misma marca de tiempo. Se puede extender la relacin de orden para conseguir una relacin de orden total aadiendo el n de proceso (Ta, Pa): marca de tiempo del evento a del proceso P (Ta, Pa) < (Tb, Pb) s y solo si Ta < Tb o Ta=Tb y Pa<Pb
Problemas de los relojes lgicos

No bastan para caracterizar la causalidad Dados RL(a) y RL(b) no podemos saber:
si a precede a b si b precede a a si a y b son concurrentes
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
Problemas de los relojes lgicos

P1 e11 (1) P2 e21 (1) P3 e31 (1) e32 (2) e12 (2) e22 (3) e33 (3)
C(e11) < C(e22), y e11e22 es cierto C(e11) < C(e32), pero e11 e32 es falso
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
Propiedades de los relojes vectoriales

RV < RV si y solo si RV RV y RV[i ] RV[i ], i Dados dos eventos a y b a H b si y solo si RV(a) < RV(b) a y b son concurrentes cuando
Ni RV(a) RV(b)[i ] ni RV(b ) RV(b)
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
Justificacin del multicast atmico

Sea un banco con una base de datos replicada para almacenar las cuentas de los clientes. Considere la cuenta X con un saldo de 1000 euros. Un usuario ingresa 200 eurosenviando un multicast a las dos bases de datos. Al mismo tiempo se paga un 10% de intereses, enviando un multicast a las dos bases de datos. Qu ocurre si los mensajes llegan en diferente a orden a las dos bases de datos?
138
Implementacin del multicast

Implementacin de operaciones multicast: Mediante operaciones punto a punto. Mecanismo poco fiable. Problemas de fiabilidad: Alguno de los mensajes se puede perder. El proceso emisor puede fallar despus de realizados algunos envos. En este caso algunos procesos no recibirn el mensaje.
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
Ejemplo de multicast sin ordenacin
P1 A A
P2
P3 B
P4
Tiempo B
141
Ordenacin de las actualizaciones

Es importante el orden en el que se realizan las peticiones Qu ocurre en un sistema asncrono cuando un cliente modifica un dato y ms tarde otro cliente quiere consultar ese dato? Algunas aplicaciones requieren un orden en la realizacin de las peticiones. Orden total: dadas dos peticiones r1 y r2 entonces o r1 es procesada en todos los procesos antes que r2 o r2 lo es antes que r1. Ordenacin causal: se basa en la relacin de precedencia que recoge las relaciones de causalidad potencial. Si r1 precede a r2 entonces r1 se procesa antes que r2 en todos los procesos
Ordenacin total y causal

t1 t2
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.
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

Clase 2

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Clase 2

Hochgeladen von

Copyright:

Verfügbare Formate

Diseo de Sistemas Distribuidos

Mster en Ciencia y Tecnologa Informtica

Flix Garca Carballeira Grupo de Arquitectura de Computadores felix.garcia@uc3m.es

Flix Garca Carballeira

Sistemas Distribuidos (2012-2013)

Flix Garca Carballeira

Sistemas Distribuidos (2012-2013)

Origen de los fallos

Flix Garca Carballeira

Sistemas Distribuidos (2012-2013)

Flix Garca Carballeira

Sistemas Distribuidos (2012-2013)

Flix Garca Carballeira

Sistemas Distribuidos (2012-2013)

Flix Garca Carballeira

Sistemas Distribuidos (2012-2013)

HW inestable Entorno inestable Error del operador

Flix Garca Carballeira

Sistemas Distribuidos (2012-2013)

Flix Garca Carballeira

Sistemas Distribuidos (2012-2013)

Flix Garca Carballeira

Sistemas Distribuidos (2012-2013)

Flix Garca Carballeira

Sistemas Distribuidos (2012-2013)

Flix Garca Carballeira

Sistemas Distribuidos (2012-2013)

Flix Garca Carballeira

Sistemas Distribuidos (2012-2013)

Flix Garca Carballeira

Sistemas Distribuidos (2012-2013)

La fiabilidad del sistema es menor

El sistema falla cuando fallan todos los componentes

Flix Garca Carballeira

Sistemas Distribuidos (2012-2013)

Flix Garca Carballeira

Sistemas Distribuidos (2012-2013)

Flix Garca Carballeira

Sistemas Distribuidos (2012-2013)

Flix Garca Carballeira

Sistemas Distribuidos (2012-2013)

Tiempo anual sin servicio

Flix Garca Carballeira

Sistemas Distribuidos (2012-2013)

Causas de deteccin no planificadas

Flix Garca Carballeira

Sistemas Distribuidos (2012-2013)

Tcnicas para aumentar la fiabilidad

Tcnicas para obtener fiabilidad

Fases en el ciclo de vida

Especificacin, diseo e implementacin

tiempo Eliminacin de fallos

Flix Garca Carballeira

Sistemas Distribuidos (2012-2013)

Limitaciones de la prevencin de fallos

Flix Garca Carballeira

Sistemas Distribuidos (2012-2013)

Flix Garca Carballeira

Sistemas Distribuidos (2012-2013)

Grados de tolerancia a fallos

Fases en la tolerancia a fallos

Flix Garca Carballeira

Sistemas Distribuidos (2012-2013)