Вы находитесь на странице: 1из 44

Tolerancia a fallas

Definiciones, conceptos y estrategias para la


tolerancia a fallas

Integrantes:

Carlos Andrs Fernndez Jalomo


Jos Luis Corts Gutirrez
Josue Pasillas Medina
Sistemas Concurrentes y Distribuidos Julio Csar Beas Lpez
Seccin: D03 Alejandro Coronado Rizo
Qu es la
tolerancia a
fallas?
Concepto y aspectos de un sistema tolerante
a fallas
La tolerancia a fallos es garantizar
que el sistema contine funcionando
de manera correcta como un todo,
incluso cuando ocurra algn fallo.

Se dice que un sistema falla cuando


no cumple su especificacin. Como
las computadoras y los sistemas
distribuidos se utilizan cada vez ms
en misiones donde la seguridad es
crtica, la necesidad de soportar las
fallas cada vez es mayor.
Un sistema consiste de un conjunto de componentes de hardware y software diseados
para proveer un servicio en especfico.

-Un defecto de un sistema ocurre cuando el sistema no desempean estos servicios de


manera especificada. Un estado errneo en un sistema es un estado en el cual podra
conducir a un fallo en el sistema.

-Un fallo es una condicin fsica anormal, las causas de un fallo incluyen: errores de
diseo (como errores en la especificacin del sistema o en la implementacin),
problemas de fabricacin, deterioro por el uso u otros problemas externos (como
condiciones ambientales adversas,interferencia electromagntica, entradas imprevistas
o el mal uso del sistema).

-Un error es una parte del estado del sistema


la cual difiere de los valores esperados.
Criterios
Proveer un diseo tolerante a fallas para cada componente no siempre tiene que ser
una opcin. La redundancia lleva asociada una serie de penalizaciones: aumento de
peso, tamao, consumo de energa, el costo, as como tiempo para disear, verificar, y
probar. Por lo tanto, un nmero de opciones tienen que ser examinadas para
determinar qu componentes deben ser tolerante a fallos:

Que tan importante es el componente?


Cul es la probabilidad de que esta componente falle?
Cul es el costo para hacer el componente tolerante a fallos?
Requisitos

Las caractersticas bsicas de la tolerancia a fallos:


1. Ni un solo punto de falla - Si un sistema experimenta un fracaso, debe
continuar funcionando sin interrumpirse durante el proceso de reparacin
2. Aislamiento de fallos en el componente que est fallando, cuando se produce
un error, el sistema debe ser capaz de aislar la falla a la reincidencia. Esto
requiere la adicin de mecanismos de deteccin de fracaso dedicados que
existen solamente para el propsito del aislamiento de falla.
3. La contencin de fallas para evitar propagacin de la falla - algunos
mecanismos de falla pueden causar fallos en el sistema mediante la
propagacin del fallo al resto del sistema.
4. Disponibilidad de modos de reversin.
Tipos de fallos

Definicin de fallos, clasificaciones y


ejemplos
Los fallos ocurren

Un Sistema Operativo Distribuido


debera funcionar para una docena o
millares de equipos, y siempre garantizar
el funcionamiento del sistema, pero
debido a problemas de comunicacin,
fallos en la informacin, o cualquier otra
situacin, se puede producir un fallo que
bloquee a todo el sistema, idlicamente
esto no debera suceder, pero siempre
hay que saber qu tipo de fallos pueden
suceder en nuestro SOD y en qu
consisten estos
Categoras de fallos

Son
Ocurren cuando desperfectos
los elementos causados por
bsicos del SO errores de
fallan, el diseo,
sistema es fabricacin,
detenido programacin o
porque es deterioro de un
necesario, y componente
necesita volver Los resultados
fsico del
a un estado de obtenidos de procesos
sistema
correcto son incorrectos y
causan un desvo de
funciones
Tipos de fallos: Sistema Operativo
Tipos de fallos: Proceso o procesador
Tipos de fallos: Componentes
Tolerancia fsica y de software:
elementos de estrategias tolerantes

La redundancia es el
mtodo general para
la tolerancia a fallas
Tcnicas de
seguridad en
sistemas
tolerantes
La seguridad en los sistemas
distribuidos se divide a menudo en 2
partes

1. Comunicacin entre usuarios y procesos, normalmente residen en mquinas diferentes.


Garantiza la comunicacin segura mediante canales seguros y ms especficamente, la
integridad y la confidencialidad del mensaje de autenticacin.

2. Autorizacin. Garantiza que un proceso obtenga solo aquellos derechos de acceso a los
recursos de un SD para los que tiene autorizacin. Un ejemplo son los controles de acceso.
Autenticacin basada en una clave
secreta compartida
EL protocolo adopta un mtodo comn
mediante el cual una parte reta a la otra a que
responda correctamente slo si la otra parte
conoce la clave secreta compartida. (protocolos
reto-respuesta).

1. A enva identidad.
2. B enva un reto
3. A descifra el reto y se lo enva a B
4. A enva reto a B
5. B descifra el reto y se lo enva a A
Autenticacin mediante un centro de
distribucin de una clave

Un SD tiene un nmero N servidores y cada uno comparte una clave secreta con los dems
teniendo N-1 servidores, por lo cual el SD maneja N(N-1)/ claves, lo cual lo vuelve poco
escalable. Esto hace que se utilice un sistema centralizado llamado KDC, el cual, comparte
una clave secreta concada uno de los servidores, pero no requiere que los otros tengan
claves compartidas, lo cual solo se manejan solo N claves. Para este tipo de comunicacin se
usa el protocolo de Needham-Shroeder.
1. A enva reto, junto con su identidad y la de
B y un id aleatorio al KDC.
2. El KDC responde al reto, la identidad de B,
y un boleto para conectar con B.
3. A conecta con B usando el boleto dado por
el KDC, la clave para conectar, junto con un
reto.
4. B responde al reto y manda uno a A.
5. A responde al reto de B
Firmas Digitales
En las transacciones(por tomar como ejemplo) entre A y B, A piensa comprar Pokemon Ultra
Sun por $800 al seor de la tienda en lnea alias B, la transaccin ser en lnea. A enva un
mensaje a B para confirmar que comprar Pokemon US en $800. adems de la autenticacin
existen por lo menos 2 cuestiones a tener en cuenta con respecto al mensaje.

- A tiene que estar segura de que Bob no cambiar maliciosamente los $800
mencionados en su mensaje a una mayor cifra, y de que luego no diga que ella
prometi ms de $800
- B tiene que estar seguro de que A no puede retractarse de que envi el mensaje solo
porque cambi de idea.
En estas cuestiones si A firma digitalmente el mensaje, de tal forma que su firma queda
vinculada de manera nica a su contenido. La asociacin nica entre un mensaje y su firma
evita que las modificaciones al ensaje pasen inadvertidas. Una de forma popula de estas
firmas es utilizar una clave pblica como RSA, cuando A realiza un mensaje m para B, lo cifa
con su clave privada y selo enva a B.

Cuando B recibe el mensaje, lo descifra con la clave pblica de A. Si puede estar seguro de
que la clave pblica de A, el descifrado de la versin firmada de m y con la comparacin
exitosa con m slo pueden significar que provino de A. A est protegida contra cualesquiera
modificaciones maliciosas por parte de de externos.
Sistemas
Operativos
distribuidos con
tolerancia a fallos
Amoeba (Introduccin)

-Est escrito en C

-Posee un lenguaje para el cmputo distribuido y paralelo llamado Orca

-No tiene concepto de mquina de origen

-El shell inicial se ejecuta en mquina arbitrarias, pero los comandos tienen porqu ejecutarse
en la misma mquina que el shell.
Amoeba (Arquitectura)

-Pila de procesadores, cada uno con su memoria local (no es necesaria la memoria
compartida). El sistema operativo se encarga de repartir el trabajo de los procesadores de
forma dinmica.

-Terminales X, uno para cada usuario.

-Servidores especializados, que por eficiencia se encontraran en ejecucin todo el tiempo y


en mquinas dedicadas a ello.
Amoeba (Micro Ncleo)

-Se ejecuta en todas las mquinas del sistema:

-Procesadores de la pila.

-Terminales.

-Servidores especializados

-Posee las siguientes tareas:

-Controlar procesos e hilos

-
Amoeba (Micro Ncleo)

-Posee las siguientes tareas:

-Controlar procesos e hilos

- Proporciona el soporte de la administracin de memoria de bajo nivel. (Segmentos)

- Soporta la comunicacin entre los procesos. Dos formas de comunicacin:

- Puntual: Un cliente enva un mensaje a un servidor y se bloquea hasta recibir respuesta.

- De grupo: Envo de mensajes de una fuente a varios destinos.


Amoeba (Tolerancia a fallos)

Para la tolerancia a fallos se usa el servidor de rplicas.

ste funciona mejor con objetos inmutables como los archivos, ya que
trabaja en segundo plano.
Mach (Introduccin)

No es un sistema operativo, sino un microncleo.

Objetivos:
Base para la construccin de otros sistemas (UNIX).
Espacio de direcciones de gran tamao
Acceso transparente a los recursos de la red.
Paralelismo del sistema y las aplicaciones.
Escalabilidad (transportar mach a un nmero ms grande de mquinas).

La emulacin del sistema operativo se lleva a cabo en el espacio de


usuario.
Mach (Microncleo)

El ncleo de Mach se encarga de las siguientes tareas.


Administra los procesos.
Administra la memoria.
Controla la comunicacin
Controla los servicios de E/S

Ventajas:
Mayor sencillez de cada parte.
Independencia y portabilidad del sistema operativo.
Ejecucin de varios sistemas a la vez.
Mayor seguridad (cada proceso tiene su propio sistema operativo. Difcil
husmear ficheros del otro sistema).
Chorus (Introduccin)

Este sistema es un proyecto del INRIA, desarrollado en 1980


[Tanenbaum, 1996]. En 1997 el Chorus fue adquirido por Sun
Microsystems.

Algunos de los objetivos de Chorus son:


Permitir una emulacin de UNIX de alto rendimiento.
Para usar en sistemas distribuidos.
Aplicaciones en tiempo real.
Integrar programacin orientada a objetos.
Permite servidores de grupo y ser reconfigurable.
Chorus (Tolerancia a fallos)

Las fallas estn restringidas a volmenes de disco y sistemas de archivos.

Para proporcionar resistencia a las fallas de disco individuales, los volmenes de


disco se duplican, de modo que si uno de los duplicadores falla, el volumen an
est disponible desde el espejo restante.

Cuando falla un nodo se pretende que el dispositivo o el sistema de archivos


est disponible desde otro nodo mediante un mecanismo de conmutacin por
error que permite el acceso al recurso tan pronto como se hayan completado las
acciones de recuperacin apropiadas.
Acuerdos en sistemas defectuosos

En muchos sistemas distribuidos existe la necesidad de que los procesos


coinciden en algo .

El objetivo general de los algoritmos de acuerdo distribuido es lograr que todos


los procesadores no defectuosos alcancen el consenso acerca de cierto tema, en
un nmero finito de pasos.
Resolucin de los generales bizantinos
Sistema Distribuido de Tiempo Real

Los sistemas tolerantes de fallas no son el nico tipo de sistemas distribuidos especializados.
Los sistemas de tiempo real forman otra categora. A veces se combinan estos dos tipos para
obtener sistemas de tiempo real tolerantes de fallas.

Los programas (y sistemas) de tiempo real interactan con el inundo exterior de una manera
que implica al tiempo. Cuando aparece un estmulo, el sistema responde a ste de cierta
manera y antes de cierto momento lmite. Si entrega la respuesta correcta, pero despus del
lmite, se considera que el sistema est fallando.
Cmo hacer un
sistema
distribuido
tolerante a fallas?
Tcnicas de tolerancia a fallos en
sistemas distribuidos

Replicacin
Crear mltiples copias de datos que sean almacenados en distintos lugares, la idea principal
de esto es que si un nodo falla, los datos pueden ser accesados de una de sus copias. Tiene
desventajas o limitaciones como consistencia de la informacin.

Checkpointing
Guardar el estado de un sistema cuando se encuentra en un estado estable y consistente,
una instancia de guardado de este estado se le llama checkpoint, si el sistema llega a fallar
durante el funcionamiento se restablece a uno de estos estados anteriores.
Tipos de replicacin

Activa
Pasiva
Replicacin Activa

Las peticiones de los clientes son


procesadas por todos los servidores

Requiere de un protocolo para reenviar las Server Server Server


peticiones a todos los servidores
Estado Estado Estado
Replicacin Pasiva o de servidor
primario

C
Solo un servidor procesa las peticiones de
los clientes y se le conoce como servidor
primario

Los dems servidores actan como


Server Server Server
servidores de respaldo en caso de falla del
servidor primario, el cual actualiza el estado Estado Estado Estado

de estos
Checkpointing

Cada sistema tiene asociada informacin que define su estado en un momento en particular.

Esta informacion incluye cosas como el estado del proceso, ambiente(conexiones, servicios
etc.) valores de los registros activos y variables.

Esta informacion es recolectada y almacenada.

En caso de un fallo el sistema es restaurado a un checkpoint anteriormente guardado, no


necesariamente en el inicio.

El checkpointing es muy til pero consume tiempo considerable dependiendo del tamao del
sistema.
Tipos de checkpointing

User triggered Requiere intervencin del usuario


Puede ser til cuando el usuario tiene conocimientos tcnicos
No es fcil identificar cundo se debe crear un checkpoint

Checkpointing Los procesos se comunican entre ellos


coordinado Primero se crean checkpoints temporales que de ser necesario se
convierten en permanentes
el tiempo de recuperacin es alto debido a la comunicacin

Checkpointing no Los procesos no se comunican entre ellos y crean sus propios


coordinado checkpoints
Sin gastos por comunicacin entre procesos

Checkpointing basado El estado de los procesos se almacena como un mensaje, si un proceso


en mensajes falla otro toma su lugar y obtiene su estado con la ayuda de los mensajes
Actividad
Actividad
Sopa de letras

Escribe con tus palabras qu significan


los siguientes conceptos y encuntralos
en la sopa de letras:
Referencias
Tanebaum Andrew. (1995). Sistemas Operativos Distribuidos. Espaa. Prentice-Hall
Hisp.

Rachit Garg, Praveen Kumar. A Review of Checkpointing Fault Tolerance Techniques in


Distributed Mobile Systems. (IJCSE) International Journal on Computer Science and
Engineering

http://dccd.cua.uam.mx/libros/archivos/03IXStream_sistemas_distribuidos.pdf

https://es.slideshare.net/Tensor/sistemas-operativos-distribuidos-linux

https://www.usenix.org/legacy/publications/library/proceedings/sd96/full_papers/kittur.txt

Вам также может понравиться