INTRODUCCIÓN.

1. Conceptos básicos y definiciones.

• Niveles de abstracción en un STF
• Confiabilidad
• Atributos de la confiabilidad
• Prevención y tolerancia
• Modelo de sistema
• Sistemas distribuidos. Punto de vista físico.
• Sistemas distribuidos. Punto de vista lógico.
• Comportamiento síncrono vs asíncrono.
• Disfunciones, errores, fallos
• Tipos de fallo
• Tolerancia a fallos

2. Fases en la tolerancia a fallos

• Fase de detección de errores
• Fase de confinamiento del daño
• Fase de recuperación de errores
• Fase de tratamiento de fallos

3. Tolerancia a fallos Hardware

• Técnicas típicas
• Redundancia Modular Triple
• Redundancia dinámica
• Codificación
• Circuitos autochequeantes

1
1.CONCEPTOS BÁSICOS.
NIVELES DE ABSTRACCIÓN EN UN STF.

• Los diferentes niveles proporcionan diferentes servicios de TF.

Niveles en un STF distribuido

Software tolerante a fallos Servicio continuo en los
fallos de diseño
Servicios Tolerantes a Procesos resistentes Servicio continuo en los
Fallos Datos resistentes fallos de los nodos
Acciones atómicas Consistencia en los fallos de
Recuperación a un estado los nodos
consistente
Difusión fiable y atómica de
mensajes
Bloques constructivos Procesadores Fallo-parada
Almacenamiento estable,
Comunicación fiable
Sistema Distribuido

• En el nivel mas bajo tenemos los bloques constructivos

básicos, que serán usados por niveles superiores. Estos son:
• Procesadores fallo-parada.
• Almacenamiento estable.
• Comunicación fiable.
• Relojes sincronizados.
• Detección de fallos.

• Para soportar TF se supone que un sistema proporciona estas

abstracciones.

• Difusión fiable y atómica de los mensajes: para soportar

abstracciones de STF donde se requiera una comunicación uno
a muchos.

• Recuperación a un estado consistente, y acciones atómicas

proporcionan consistencia en los fallos. Con acciones atómicas
una acción se aborta si tenemos una avería mientras la acción
se está ejecutando.

2
• Resistencia de datos y resistencia de procesos, las acciones
siempre se completan, incluso en caso de presencia de averías,
y los datos sobre los que las acciones o procesos operan deben
estar accesibles incluso si hay fallos.

• Sw tolerante a fallos: pretende que el sw pueda enmascarar

sus propios fallos.

CONFIABILIDAD

• En muchas áreas las computadoras hacen tareas de las que

dependen vidas. Se necesitan sistemas altamente confiables.

• Confiabilidad (dependability): La confianza que se puede

poner en un sistema de computación tal que ésta pueda ser
justificada.

La confiabilidad tiene varios atributos:

Fiabilidad (reliability)
Disponibilidad (availability)
Resguardo (safety)
Seguridad (security)

ATRIBUTOS DE LA CONFIABILIDAD

• La fiabilidad trata de la continuidad de servicio.

• La disponibilidad trata del porcentaje de tiempo en que el

servicio está disponible para su uso.

• El resguardo trata de la evitación de consecuencias

catastróficas en el entorno.

• La seguridad trata sobre el intrusismo de personas, prevención

de accesos no autorizados y/o manejo de información.

3
PREVENCIÓN Y TOLERANCIA

• Una disfunción o avería ocurre cuando el servicio de un

sistema no es consistente con su especificación.

• La disfunción de un sistema se produce por el fallo de alguno

de sus componentes.

• Para mejorar la fiabilidad de un sistema se puede hacer:

• prevención de fallos y/o
• tolerancia a fallos

• La prevención de fallos utiliza métodos para impedir que se

presenten fallos en los componentes.

Estos métodos pueden ser: de diseño, de test y de validación.

A pesar de la prevención de fallos, se presentan fallos

durante el funcionamiento del sistema.

• Para obtener más fiabilidad necesitamos tolerancia a fallos, su

objetivo es que el sistema cumpla con su especificación a pesar
de la presencia de fallos. Es una técnica complementaria de la
prevención.

• La tolerancia a fallos usa redundancia protectora para

enmascarar fallos. Si un componente falla se usa uno
redundante.

• Se asume que las técnicas de prevención y/o tolerancia

NUNCA podrán eliminar todos los posibles fallos del sistema.

4
MODELO DE SISTEMA

• Un sistema es un mecanismo identificable que mantiene un

patrón de comportamiento en el interfaz con su entorno. Un
sistema debe interarctuar con su entorno. La especificación del
entorno define los límites del sistema de interés.

• La arquitectura interna de un sistema puede particionada como

una jerarquía sistema/subsistema , con cada partición teniendo
su propio modelo de comportamiento en el sistema global.

EJEMPLO: Un sistema de ficheros consta de dos subsistemas:

gestor de espacio en disco y un servidor de E/S a disco.

• A los subsistemas más bajos dignos de interés se les llama

componentes atómicos.

• En un sistema distribuido los componentes atómicos son:

memoria, CPU, disco, y red de interconexión.

• El estado externo de un sistema es su comportamiento

externo.

• El estado interno de un sistema es el estado externo de sus

subsistemas.

• Las especificaciónes de un sistema nos dicen si un

comportamiento es correcto o no. Las especificaciones de un
sistema deben ser completas, consistentes y correctas.

5
SISTEMAS DISTRIBUIDOS. PUNTO DE VISTA FÍSICO.

• Un Sistema Distribuido es un conjunto de procesadores

(workstations, microcomputadores,...) conectados a través de
una red de comunicación.

• Los procesadores se comunican en la red a través del

intercambio de mensajes.

• No comparten memoria.

• No existe un reloj global.

SISTEMAS DISTRIBUIDOS. PUNTO DE VISTA LÓGICO.

• Aplicación distribuida: Un conjunto de procesos cooperantes

que se están ejecutando sobre múltiples procesadores.

• No se hace ninguna suposición sobre las velocidades relativas

de ejecución cuando se desarrollen o analicen las aplicaciones
distribuidas.

• No hay consideraciones sobre la topología, los protocolos de

comunicación aseguran que todos los procesadores se
comuniquen entre sí.

• Un canal permite el envío de mensajes entre dos procesadores.

• Se asume que los canales están generalmente libres de error y

se comportan como una estructura FIFO (los protocolos de
comunicación aseguran estas propiedades).

• Generalmente, no hay un orden total de los mensajes, esto es,

no se hacen suposiciones sobre el orden de los mensajes que
lleguen a través de los diferentes canales.

6
COMPORTAMIENTO SINCRONO VS ASINCRONO.

• Canal de comunicación síncrono: El retardo máximo de un

mensaje es conocido y finito.

• Canal de comunicación asíncrono: No hay suposiciones

sobre el máximo retardo del mensaje (pero es finito).

• Proceso síncrono: El tiempo máximo de ejecución para un

conjunto de instrucciones es conocido y finito.

• Proceso asíncrono: No hay suposiciones sobre el máximo

tiempo de ejecución.

DISFUNCIONES, ERRORES, FALLOS

• Suponemos que un sistema tiene una especificación asociada,

que describe su comportamiento normal.

• Una disfunción (failure) ocurre cuando el comportamiento del

sistema se desvía de su especificación, el sistema tiene una
disfunción o avería cuando no puede proporcionar el servicio
deseado.

• Un error es la parte del estado interno (del sistema) que puede

producir disfunciones (es decir, que elemento puede causar la
desviación del comportamiento del sistema).

Si hay un error en el sistema, existe una secuencia de acciones

que ejecutadas nos llevarán a una disfunción del mismo.

• Los errores son causados por fallos (faults). Los fallos son las
disfunciones de los subsistemas. Es la parte del sistema que
causa un error y por tanto una disfunción del mismo.

• Es más fácil detectar errores que disfunciones. El estado

externo de un sistema puede avisar de estos errores.

7
• La presencia de una disfunción se suele deducir detectando
algún error en el estado del sistema.

EJEMPLO:
Fallo: Un bit de memoria se pone al otro estado.
Error: La variable X se afecta por este problema.
Disfunción: El sistema da malos resultados pues la variable X
tiene un valor fuera de rango.

TIPOS DE FALLO

• Los fallos pueden ser transitorios o permanentes

• Los fallos transitorios son de corta duración y difíciles de

detectar. También se les llaman fallos intermitentes.

• En los fallos permanentes el componente que ha fallado no

empieza a funcionar correctamente de nuevo de forma
expontanea.

• Dependiendo de la fase de su introducción, los fallos pueden

ser: de diseño u operacionales.

• Los fallos de diseño se deben a un componente hw o sw

incorrectamente diseñado.

• Los fallos operacionales tienen causas físicas (corte de fluido

eléctrico, rotura de un componente del sistema...) y son más
fáciles de tolerar que los de diseño. Estos fallos ocurren
durante la operación del sistema.

• Es difícil trabajar con fallos de un sistema en tiempo de

ejecución, luego solo consideraremos fallos operacionales.

8
TOLERANCIA A FALLOS

• Un sistema es tolerante a fallos si puede enmascarar fallos de

sus componentes usando redundancia (esto es, si su
comportamiento queda consistente con la especificación del
sistema a pesar de sus fallos).

• Una tolerancia a fallos total es imposible.

• Una técnica de tolerancia a fallos se caracteriza por la

funcionalidad a conservar del sistema y los tipos de fallos a
tratar.

• Pretendemos mantener algunos servicios (posiblemente con

menos eficiencia) a pesar de que algunos componentes fallen.

• Redundancia, clave de la tolerancia a fallos. Se define como

las partes del sistema no necesarias si no hay fallos.

• La redundancia de un sistema puede ser:

• Hardware, hw extra que se añade para sustituir a los

componentes que fallan.

• Software, sw extra para ayudar a la tolerancia de fallos (

ejemplo: ejecutar idéntico código en múltiples procesadores
y ver si todos responden de la misma manera).

• De tiempo, repetir varias veces en el tiempo una mísma

operación.

9
2. FASES EN LA TOLERANCIA A
FALLOS
1. Detección de errores
2. Confinamiento del daño
3. Recuperación de errores
4. Tratamiento del fallo y reanudación del servicio

FASE DE DETECCIÓN DE ERRORES.

• Los fallos y disfunciones se van a detectar a través de la

presencia de errores.

• ¿Cómo determinar que una condición de error existe?

• Idealmente el hw/sw usado en la detección debe ser

independiente del hw/sw que se está monitorizando, pero esto
es muy difícil.

• Los errores se detectan con chequeos. El chequeo ideal es muy

difícil de conseguir. Se utilizan chequeos de aceptabilidad, que
tienen un coste razonable y cazan la mayoría de los errores.

• Chequeos típicos son:

• replicación (duplicar la computación)
• tiempo (tiempo empleado en la computación)
• estructurales y códigos de verificación (¿los datos
parecen correctos?)
• razonabilidad (¿son los valores razonables?)
• diagnóstico (computar un resultado conocido).

• Los chequeos de replicación replican componentes de un

sistema y realizan comparación de sus resultados. Si los fallos
son de diseño las réplicas deben ser distintas. Este método es
muy caro.
Ejemplo: Redundancia Modular Triple.

10
• Los chequeos de tiempo utilizan temporizadores de vigilancia
(watchdog) para detectar comportamientos temporales fuera de
lo especificado. Se usan tanto en HW como en SW.
EJEMPLO: comprobaciones de tiempo para detectar
problemas en acceso a memoria o al bus.

• Los chequeos estructurales y códigos de verificación usan

codificación redundante en los datos para detectar su
corrupción.
EJEMPLO: Uso de paridad, códigos detectores y correctores
(e.d. robustos)

• Los chequeos de razonabilidad usan rangos y aserciones para

asegurar que un dato tiene un valor dentro de lo razonable. El
rango de valores aceptables está determinado por la aplicación.
EJEMPLO: Declaraciones de límites de array en Pascal, que
genera verificación de rango en tiempo de ejecución.

Una aserción es una expresión lógica del valor de diferentes

variables en el sistema que se verificarán si el estado de éste es
consistente.

• Los chequeos de diagnóstico los realiza el sistema sobre sus

componentes antes de entrar en servicio. Los chequeos de
diagnóstico son valores de entrada especiales para los que es
conocido la salida que debe proporcionar el sistema.

11
FASE DE CONFINAMIENTO DEL DAÑO

• Necesitamos saber que partes del sistema están afectadas.

• Desde que ocurre un fallo y se detecta el estado erróneo pasa

un tiempo. Durante ese tiempo el estado erróneo puede haberse
extendido, por lo que hay que determinar dicha extensión.

• Podemos identificar los límites dinámicamente registrando

todo el flujo de información.

• Es mucho más sencillo si el sistema está diseñado con barreras

que no pueden ser atravesadas por el flujo de información.

FASE DE RECUPERACIÓN DE ERRORES

• Esta fase trata de pasar el sistema a un estado consistente.

• Hay dos técnicas: recuperación hacia atrás y recuperación

hacia adelante

• La recuperación hacia atrás devuelve el sistema a un estado

pasado consistente. No depende del fallo ocurrido y se
comporta bien con fallos transitorios, aunque tiene el coste de
guardar estados y de recuperarlos.

• La recuperación hacia adelante lleva al sistema a un estado

consistente no pasado. Es menos costoso pero necesita un
conocimiento perfecto del fallo. Es generalmente dependiente
de la aplicación por que debemos saber la extensión del error y
como superarlo.

12
FASE DE TRATAMIENTO DE FALLOS Y
REANUDACIÓN DEL SERVICIO

• Si el fallo es permanente, no sirve sólo con la recuperación de

errores, necesitamos una fase de tratamiento de fallos.

• Esta fase tiene dos partes:

• localización del fallo
• reparación del sistema

• En la localización del fallo, éste suele estar situado en el

componente más cercano a la fuente de error.

• La reparación del sistema debe ser en ejecución y se hace

mediante reconfiguración dinámica con componentes
redundantes.

• Debemos asegurarnos que el fallo no causa otro error mientras

el sistema está siendo recuperado.

13
3. TOLERANCIA A FALLOS HARDWARE
• A pesar de realizarse tests en todas las fases de su fabricación,
el hardware sigue teniendo fallos.

• El origen de los fallos hardware es físico y puede presentarse

tanto en la fase de fabricación como en la de uso.

• Se puede estudiar el efecto de los fallos físicos en diferentes

niveles de abstracción.

• Se pueden tener modelos de fallos a escala de: puertas lógicas,

funcional, de memorias,...

TÉCNICAS TÍPICAS

• Las técnicas más comunes de tolerancia a fallos hardware son:

• Redundancia modular triple (RMT)
• Redundancia dinámica
• Codificación
• Circuitos autochequeantes

REDUNDANCIA MODULAR TRIPLE

• Con esta técnica la unidad hardware se triplica. Tienen la

misma entrada y ejecutan en paralelo.

• La salida de las tres réplicas se pasa a un elemento votador que

compara y entrega el valor mayoritario.
M

Entrada M V
salida

14
• La RMT es más adecuada para fallos transitorios ya que no se
elimina la réplica fallida.

• Sólo tolera un fallo a la vez, aunque si la votación se hace bit a

bit, a veces se pueden tolerar dos fallos.

• ¡Si el fallo es permanente, RMT es menos fiable que una sola

réplica!. Además, el votador y el reloj son puntos únicos de
fallo.

• Una generalización de RMT es RMN con N replicaciones.

REDUNDANCIA DINÁMICA

• Un sistema con redundancia dinámica contiene varias unidades

pero solo una puede estar operando a la vez.

• Estas técnicas se pueden clasificar en: redundancia en frío y

redundancia en caliente.

• Con la redundancia en frío, la unidad tiene varias réplicas,

pero sólo una activa.

• Cuando la réplica activa falla, se desconecta y se conecta una

de las de reserva.

• Los fallos se detectan: por test periódicos, por circuitos

autochequeantes, o por temporizadores de vigilancia.

• Con la redundancia en caliente, varias réplicas trabajan a la

vez. Se comparan sus salidas y se escoge una de ellas.

• Si las salidas son distintas, se elimina la unidad fallida

15
CODIFICACIÓN

• Esta técnica se basa en añadir información redundante a los

datos que permite detectar y corregir corrupciones.

• Para palabras cortas se usan códigos de Hamming.

• Para bloques de datos se usan códigos de redundancia cíclica

(CRC).

CIRCUITOS AUTOCHEQUEANTES

• Un circuito autochequeante consta de una parte funcional cuya

salida está codificada y un chequeador que la comprueba.

• El chequeador debe ser capaz de detectar un error en la salida y

en su propio circuito.

16