Desarrollo de Aplicaciones

Distribuidas
3º Grado en I. de Tecnologías de Telecomunicación

Tema 8: Tolerancia a fallas

23 de noviembre de 2020

Presentación correspondiente al Capítulo 8 del libro:

A.S. Tanenbaum, M.V. Steen. Distributed Systems, Principles and
Paradigms, Second Edition. Ed. Pearson Prentice Hall. 2007.
Índice
8.1. Introducción
8.1.1. Conceptos básicos
8.1.2. Modelos de fallo
8.1.3. Redundancia (enmascaramiento de fallos)

8.2. Resiliencia de un componente

8.2.1. Enmascaramiento de fallas y acuerdos en sistemas
defectuosos

2
 8.1. Introducción
• En un sistema se produce un fallo cuando no puede ofrecer el
servicio que promete y para el que fue originalmente
concebido/diseñado.
• Una característica peculiar de los sistemas distribuidos (y de los
sistemas modulares, de manera más general), en contraposición
con los sistemas monolíticos, es el concepto de «fallo parcial»
(partial failure): consiste en el fallo de un solo componente, es
decir, de una única parte del sistema.
• Uno de los objetivos de diseño de un sistema distribuido es la
tolerancia a fallas o la tolerancia a fallos parciales: ante un
fallo parcial, el sistema debe ser capaz de seguir funcionando
hasta que el fallo parcial sea subsanado.
• El principal mecanismo para alcanzar una tolerancia frente a
fallas es el empleo de redundancia.
3
 8.1.1. Conceptos básicos

• La tolerancia a fallas está íntimamente ligada con el concepto

de sistemas confiables (dependable systems).

• La confiabilidad (dependability) cubre los siguientes requisitos

en un sistema distribuido:
• Disponibilidad (availability)
• Fiabilidad (reliability)
• Seguridad (safety)
• Mantenibilidad (maintainability)

4
 Disponibilidad (availability)

• Propiedad de que un sistema esté listo para ser usado en el

momento. Probabilidad de que el sistema esté funcionando
correctamente en un momento determinado y esté disponible
para ofrecer el servicio que realiza.

Fiabilidad (reliability)

• Propiedad de que un sistema pueda estar funcionando de manera

continua sin fallos. Intervalo de tiempo durante el que un
sistema no presenta fallos. Normalmente se presenta con el
valor del tiempo medio entre fallos (MTBF, del ingles Mean
Time Between Failures)

5
 Disponibilidad (availability) vs fiabilidad (reliability)

• Conviene entender bien la diferencia entre los conceptos de

disponibilidad y fiabilidad. Para ello, veamos dos ejemplos:

• Un sistema falla durante un milisegundo cada hora, de manera

aleatoria.
• Disponibilidad:
3600 𝑠𝑠 − 0.001 𝑠𝑠
≈ 0.99999 𝟗𝟗𝟗𝟗. 𝟗𝟗𝟗𝟗𝟗𝟗% del tiempo dis𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝
3600 𝑠𝑠
• Fiabilidad: tiempo medio entre fallos de 1 hora

• Un sistema falla, en promedio, una vez cada 10 años, pero

dicho fallo permanece durante medio año cuando sucede.
10 años −0.5 años
• Disponibilidad: = 0.95 (𝟗𝟗𝟗𝟗%)
10 años
• Fiabilidad: 10 años

6
 Seguridad (safety)

• Propiedad que alude a la criticidad del fallo del sistema. En

una situación en la que el sistema falla por completo, incluso por
un tiempo breve, dicho evento no debe conllevar consecuencias
catastróficas. Este requisito es especialmente importante en
sistemas de los que dependen vidas humanas (p. ej. control de
plantas nucleares).

Mantenibilidad (maintainability)

• Propiedad que se refiere a la facilidad de reparación de un

sistema que ha fallado. Típicamente esa facilidad se traduce en
un menor tiempo de reparación, lo que conlleva una alta
disponibilidad del sistema.

7
 Otros conceptos

• Una falla/defecto (fault) es una parte del estado de un sistema

que puede dar lugar a un fallo. Por ejemplo, un cable en mal
estado.
• Un error es una parte del estado de un sistema que puede hacer
que el sistema falle. Por ejemplo, un error podría ser la
corrupción de un paquete que se envía por ese cable.
• Un fallo (failure) es la manifestación en un sistema de la
imposibilidad de operar de manera correcta. Por ejemplo, un
fallo podría ser el corte repentino de una llamada de voz que se
está llevando a cabo entre dos usuarios del sistema.

8
 Tipos de fallos según su aparición

• Fallos transitorios: ocurren una vez y luego desaparecen. Si la

misma operación se repite, el fallo no se manifiesta de nuevo.
Suelen aparecer por causas anómalas puntuales (p. ej. un ave se
interpone en la línea de visión de una comunicación FSO).

• Fallos intermitentes: el fallo sucede y desaparece de manera

aparentemente aleatoria y sin un motivo aparente claro. Son
difíciles de diagnosticar. Ej.: un contacto flojo de un terminal
RJ-45 puede producir este tipo de fallos.

• Fallos permanentes: es aquel fallo que existe de manera

consistente hasta que el componente que falla es reemplazado.
Ej.: chip «quemado», bug en software, rotura del cabezal de un
disco duro magnético, etc.
9
 8.1.2. Modelos de fallo
La mayor parte de los fallos de los sistemas pueden clasificarse en
uno de los tipos de fallo siguientes:

Tipo de Fallo Descripción o ejemplo

Fallo de congelación
Fallo de omisión
Fallo de omisión de recepción
Fallo de omisión de envío
Fallo de tiempo
Fallo de respuesta
Fallo de respuesta de valor
Fallo de transición de estado
Fallo arbitrario o fallo bizantino
Un servidor se detiene, pero estaba trabajando correctamente hasta que se detuvo
Un servidor no responde a peticiones entrantes
Un servidor no recibe los mensajes entrantes
Un servidor no envía mensajes
La respuesta de un servidor queda fuera del intervalo de tiempo especificado
La respuesta de un servidor es incorrecta
El valor de la respuesta está equivocado
El servidor se desvía del flujo de control correcto
Un servidor puede producir respuestas arbitrarias en tiempos arbitrarios. Ocurren
cuando el fallo es difícilmente detectable como incorrecto.

10
8.1.3. Redundancia o replicación para el enmascaramiento
de fallos
• Para esconder los fallos parciales que suceden en un sistema, y
alcanzar una elevada tolerancia a fallas, se recurre a la
redundancia o replicación de recursos/componentes.

• Tres tipos de redundancia:

• Redundancia de información: añadir bits adicionales para
recuperar corrupción de bits (Hamming code, CRC).
• Redundancia de tiempo: una acción se realiza, y si es
necesario, se lleva a cabo de nuevo (reenvío cuando vence un
temporizador). Útil con fallos transitorios o intermitentes.
• Redundancia física: equipamiento extra o procesos que se
añaden para permitir que el sistema tolere el fallo de algunos
de sus componentes. Puede ser en hardware o software.
11
Ejemplo de redundancia física. En (b) se utiliza redundancia
modular triple, en la que tres circuitos A, B, y C se triplican, y un
sistema de votantes (también triplicado por si falla el votante)
selecciona la salida más común

12
 8.2. Resiliencia de un componente
• Según el diccionario de la lengua española, la resiliencia es la capacidad de
adaptación a situaciones adversas
• Para afrontar la tolerancia a un proceso defectuoso se organizan varios
procesos idénticos en grupo. Cuando un proceso se envía al grupo, todos
los miembros lo reciben. El grupo trabajará de modo que aunque falle un
proceso del grupo, la respuesta del sistema sea correcta. Por ejemplo, una
opción posible sería que todos los miembros diesen su respuesta, y se
tomase la respuesta más común.
• Podemos tener grupos
planos (entre iguales,
como los sistemas basados
en Tablas Hash
Distribuidas) o grupos
jerárquicos (un miembro
es el coordinador), aunque
en esto últimos si el
coordinador falla, el grupo
13
se detiene .
Enmascaramiento de fallas

• Un punto clave, cuando se emplean grupos de componentes para

mitigar los fallos, es cuánta replicación es necesaria.
• Un sistema se dice que es tolerante a k fallas si puede
sobrevivir al fallo en k componentes y todavía funcionar
correctamente como un todo.

Enmascaramiento de FALLOS SILENCIOSOS:

• Si k componentes simplemente dejan de funcionar, sin ofrecer
respuesta, en ese caso la respuesta de un único servidor activo
sería suficiente.
• Tener k + 1 componentes es suficiente para tolerar k fallos en
este caso.

14
Enmascaramiento de FALLOS BIZANTINOS:
• Si k componentes pueden fallar de manera arbitraria, ofreciendo
resultados erróneos, entonces se necesita tener una mayoría de
componentes que funcionen correctamente, para poder
discriminar el valor correcto mediante un sistema de votado por
mayoría.
• El peor escenario sería tener que los k fallos suministran el
mismo valor (equivocado), de manera que necesitamos al
menos el mismo número de componentes correctos, más uno
para deshacer el empate del voto.
• Tener 2·k + 1 componentes es suficiente para tolerar k fallos en
este caso.

15
 Acuerdos en sistemas defectuosos
• Los algoritmos de acuerdos distribuidos pretenden que todos los
procesos no defectuosos lleguen a un consenso en algún tema,
utilizando para ello un algoritmo con un número finito de pasos.
• Es más complejo llegar a acuerdos que enmascarar fallas. La
complejidad se conoce como problema del acuerdo bizantino.
• Para llegar a un acuerdo en un sistema defectuoso con k fallas, hacen
falta 3⋅k+1 procesos, como se ve en las 4 siguientes diapositivas.

16
17
18
19
20
• Cuando hay 1 traidor, se requieren 2 rondas de mensajes para llegar al
acuerdo detectando al traidor.
• Cuando hay t traidores se requieren t+1 rondas de mensajes para
llegar al acuerdo detectando al traidor.
• Es más complejo llegar a acuerdos que enmascarar fallas. La
complejidad se conoce como problema del acuerdo bizantino.

del 2 del 1
del 3 del 3

Ni 1 ni 2 detectan al traidor, ni llegan a consenso

del 2 del 1 del 1

del 3 del 3 del 2

del 4 del 4 del 3

1, 2 y 4 detectan que el 3 es traidor, y llegan a un consenso

21
Fin del tema