Pgina 1

Contenido

Introduccin .............................................................................................................................................. 3
Administracin de replicas ................................................................................................................... 4
Replicacin mediante primario y respaldos ................................................................................. 6
Comunicacin en grupos ................................................................................................................... 7
Compromiso distribuido .................................................................................................................... 9
Transacciones....................................................................................................................................... 9
Sincronizacin y coordinacin distribuida ..................................................................................... 11
Mecanismos de sincronizacin entre procesos ........................................................................ 11
Mecanismos de sincronizacin distribuida ............................................................................ 12
Conclusin ............................................................................................................................................... 13

2
Pgina
Introduccin

Un sistema distribuido es una coleccin de nodos autnomos de computacin que

se pueden comunicar unos con otros y que colaboran en un objetivo o tarea comn.

Cuando un nodo falla o cuando el subsistema de comunicaciones que permite que los
nodos se comuniquen falla, los nodos se han de adaptar a las nuevas condiciones, para
que puedan seguir cooperando.

En los sistemas tolerantes a fallo, los fallos que se pueden tolerar son aqullos que est
previsto que pueden ocurrir. El primer paso necesario para que un sistema pueda
recuperarse de un fallo, es detectarlo. El siguiente paso es llevar al sistema a un estado
consistente, para ello, es necesario que las acciones realizadas antes del fallo
mantengan la consistencia. La clave para tolerar fallos es la replicacin, es decir, que
varios elementos del sistema puedan dar el mismo servicio.

3
Pgina
Administracin de replicas

La replicacin activa (conocida tambin como replicacin mediante mquina de estados)

es un mtodo general para construir un sistema tolerante a fallos mediante la replicacin
de sus elementos y la coordinacin de las comunicaciones entre ellos.

Una mquina de estados est compuesta por un conjunto de variables (estado) y un

conjunto de operaciones que modifican o consultan el valor de esas variables. Cada
operacin se realiza mediante un programa determinista, y su funcionamiento es atmico
respecto al de otras. Las operaciones tambin producir resultados de salida. Cuando un
cliente quiere ejecutar un servicio de la mquina de estados, le hace una peticin,
indicando qu operacin debe ejecutar. El resultado puede ser la activacin de un
actuador o la respuesta a algn cliente que la estaba esperando. Es necesario tambin
que las peticiones que recibe una mquina de estados sean atendidas de una en una,
en un orden que ha de ser consistente con la causalidad potencial entre ellas.

La propiedad fundamental que caracteriza una mquina de estados es que los resultados
de salida que produce estn completamente determinados por la secuencia de peticiones
que recibe, con independencia del momento en que las recibe y de cualquier otra
actividad del sistema. Una gran ventaja de este enfoque consiste en que casi cualquier
sistema puede descomponerse en clientes y mquinas de estados, por lo que puede ser
utilizado en gran parte de los casos.

Para conseguir una versin tolerante a t fallos de una mquina de estados podemos
replicarla, colocando cada rplica en un nodo diferente de la red. Si todas las rplicas
comienzan en el mismo estado, y reciben la misma secuencia de peticiones, todas harn
lo mismo, y producirn los mismos resultados. El nmero de rplicas que son necesarias
para tolerar t fallos depende del modelo de fallo que se considere. Si son fallos bizantinos,
4

hacen falta como mnimo 2t + 1, y para obtener resultados correctos basta con tomar los
Pgina
que producen la mayora de las rplicas. Si se considera que slo puede haber fallo-
parada, basta con t + 1 rplicas.

En otras palabras, la clave para conseguir mquinas de estados replicadas tolerantes a

fallos est en garantizar la coordinacin entre las rplicas (todas reciben y procesan la
misma secuencia de peticiones). Este requisito puede a su vez descomponerse en dos:
concenso (todas las rplicas correctas reciben el mismo conjunto de peticiones) y
orden (todas las rplicas correctas procesan las peticiones que reciben en el mismo
orden).

Los algoritmos de comunicacin que satisfacen el requisito de acuerdo (concenso) deben

conseguir que un emisor pueda enviar un mensaje a los receptores cumpliendo dos
condiciones: todos los receptores correctos estn de acuerdo en el mensaje que reciben
y, si el emisor es correcto, lo que cada receptor correcto recibe es lo que envi el emisor.
Los que garantizan estas dos condiciones se llaman protocolos de radiado fiables,
protocolos de acuerdo bizantino o, simplemente, protocolos de concenso.

El requisito de orden suele satisfacerse aadiendo informacin de orden a los mensajes.

Esta informacin puede ser aadida por uno de los receptores (que luego la distribuye a
los dems), o por los emisores, mediante el uso de algn tipo de reloj lgico
(generalmente, combinado con cierto acuerdo entre los receptores).

Consideremos un objeto x, y la invocacin de la operacin [x op(arg) ] por parte del cliente

La peticin se enva a todas las rplicas de x.

1. Cada rplica procesa la peticin, actualiza su estado, y enva la respuesta [x

ok(res) ] al cliente .
2. El cliente espera hasta que recibe la primera respuesta, o hasta que recibe todas
las respuestas. Si las rplicas no se comportan de manera maliciosa (es decir, no
5
Pgina

se producen fallos bizantinos), entonces el proceso cliente espera slo por la

 primera respuesta. En caso contrario, ser necesario disponer al menos de 2f + 1
rplicas para tolerar hasta f posibles fallos. En esta situacin, el cliente espera a
recibir slo f + 1 respuestas idnticas.

Replicacin mediante primario y respaldos

En los sistemas que usan este enfoque para lograr tolerancia a fallos, los emisores
envan mensajes slo al proceso marcado como primario. Si ste falla, uno de los
respaldos toma su lugar. Los clientes deben darse cuenta de estas cadas y actualizar el
primario para poder enviar sus mensajes al proceso adecuado.

Ms formalmente, para que un protocolo pueda ser considerado del tipo primario-
respaldos, deben cumplir las siguientes condiciones:

Existe un predicado que se puede aplicar al estado de cada servidor. En cualquier

momento, como mucho un servidor satisface ese predicado. El que lo satisface es
denominado primario.
Todo cliente mantiene informacin sobre la identidad de un servidor, al que realiza sus
peticiones. Este servidor, si es el primario, encola las peticiones y las atiende de una en
una.
Si una peticin llega a un servidor que no es el primario, se descarta.
6

El servicio replicado aparece, en su conjunto, como un servidor que, en el peor de los

Pgina

casos, no responde durante un nmero limitado de perodos finitos de tiempo.

Las tres primeras propiedades definen cmo debe ser el protocolo entre los clientes y el
servicio y la cuarta indica en qu condiciones el servicio debe satisfacer las peticiones.

Comunicacin en grupos

La comunicacin en grupo asume un papel importantsimo a la hora de crear sistemas

distribuidos tolerantes a fallos. Ello es as puesto que, para poder ofrecer tolerancia a
fallos a una aplicacin determinada, no es suficiente con replicar dicha aplicacin, sino
que adems es necesario disponer de un sistema que facilite la comunicacin entre tales
rplicas.

En un modelo de comunicacin con grupos dinmicos, los procesos podrn unirse o

abandonar el grupo cuando lo deseen, haciendo que la membresa pueda cambiar a lo
largo del tiempo. Al conjunto de procesos que forman parte de un grupo se le conoce con
el nombre de vista. Existir por tanto un servicio de membresa que se ocupar de
mantener actualizada la vista en cada uno de los miembros del grupo.

Las herramientas software para comunicacin con grupos utilizan una arquitectura
conocida con el nombre de 3T (three-tier). En este modelo los clientes (client-tier)
interactan con una capa intermedia (middle-tier) que se encarga de enviar las peticiones
a los servidores replicados (end-tier), manteniendo en todo momento la consistencia.
7
Pgina
Para lograrlo, la capa intermedia anida dos componentes bsicos, el secuenciador y el
manejador de replicacin activa, que se encargan de garantizar que todas las rplicas
reciben y ejecutan las peticiones de los clientes en el mismo orden en que fueron
enviadas.

Las herramientas para comunicacin con grupos proporcionan un conjunto de servicios

y primitivas que ayudan a los desarrolladores a construir sistemas de alta disponibilidad
utilizando replicacin software. En un sistema de este tipo se distinguen dos bloques
fundamentales, (i) la API y (ii) el ncleo del sistema.

El primer bloque lo constituye un conjunto de interfaces que permiten a la aplicacin

utilizar los servicios ofrecidos por la herramienta para comunicacin de grupo; el segundo
bloque implementa tales servicios. Ambos bloques pueden ser implementados usando
diferentes lenguajes de programacin.

En caso de considerar herramientas de comunicacin con grupos escritas en Java, es

importante tener en cuenta cmo puede afectar al rendimiento la localizacin de la
Mquina Virtual (JVM). Si slo la API est escrita en Java, entonces la JVM estar
ubicada bajo este bloque, permitiendo al ncleo intercambiar mensajes a travs de la red
utilizando llamadas nativas al sistema. Por el contrario, si el ncleo tambin est escrito
en Java, la comunicacin con la red habr de realizarse a travs de la JVM, lo cual puede
afectar negativamente al rendimiento.
8

Otro factor importante a la hora de elegir una herramienta de comunicacin con grupos
Pgina

es su capacidad para adaptarse a las necesidades del usuario, pudiendo tener sistemas
monolticos y sistemas modulares. En un sistema monoltico no se permite al usuario
adaptar el sistema, sin embargo, en un sistema modular el usuario es libre para adaptar
el sistema a sus necesidades configurando la pila de protocolos de la forma que
considere ms oportuna.

Compromiso distribuido

Transacciones para agrupar un conjunto de peticiones efectuadas sobre un conjunto de

elementos.

O todas tienen xito: commit - Si alguna falla: rollback de todas las operaciones.

Cada operacin debe estar preparada a que se le ordene deshacer los cambios: No es
posible en general si algn elemento no colabora (por ejemplo: una impresora)
Protocolos de compromiso: Un proceso coordina la transaccin y los dems participan
con sus votos: Compromiso en dos fases: el coordinador enva PREPARAR y los dems
responden OK o NOK. Si alguno respondi NOK, el coordinador enva ABORT. Si todos
respondieron OK, el coordinador enva COMMIT.

Problema si el coordinador y un participante fallan antes de que el coordinador enve

COMMIT/ABORT. Se bloquea a los dems participantes, que no saben qu dijo el
elemento que fall.

Solucin: compromiso en 3 fases: Preparar, precommit y commit.

Transacciones

Los sistemas distribuidos son potencialmente muy fiables debido a la posibilidad de

proveer redundancia y autonoma de recursos en diferentes nodos, esto permite detectar
y localizar fallas, sin embargo, comnmente tenemos varios aspectos que representan
problemas para la integridad de los recursos y que a su vez motivan el uso de
transacciones:
9
Pgina
Las transacciones son un mecanismo que ayuda a simplificar la construccin de sistemas
confiables a travs de procesos que proveen soporte uniforme para invocar y sincronizar
operaciones como:

Operaciones de comparticin de datos. Aseguramiento de la sociabilidad de las

transacciones con otras. Atomicidad en su comportamiento. Recuperacin de fallas
provocadas en red y nodos.

El trmino transaccin describe una secuencia de operaciones con uno o ms recursos

(por ejemplo, una base de datos) que transforman su estado actual en un nuevo estado
de consistencia. El manejo de transacciones fue desarrollado en el campo de las
operaciones financieras donde se tena 3 reglas bsicas:

1.Consistencia: Obedecer ciertas reglas. 2 Atomicidad: Debe ocurrir completo o abortar.

3 Durabilidad: Una vez iniciada una transaccin y terminada completamente no puede
ser abortada.

La teora de las transacciones consiste en una serie de modificaciones(transacciones) a

un determinado recurso del sistema (por ejemplo, una base de datos) y en donde se
define un punto de inicio (Begin Tran) y un punto determinacin que define un bloque
entre el conjunto de operaciones que son realizadas. Dentro de este proceso en bloque
los dems usuarios no pueden modificar nada hasta que no se presente un estado
estable de los datos, esto ocasiona inconsistencia temporal y conflictos.

10
Pgina
Sincronizacin y coordinacin distribuida

Estos son los mecanismos que se basan en la existencia de una unidad de sincronizacin
centralizada, la cual debe tener un nombre Tcnico conocido para todos los procesos
que requieren ser sincronizados.

Se designa un nodo como nodo de control y su tarea es administrar el acceso a los

recursos compartidos. Este nodo tambin almacena informacin relevante sobre todos
los procesos que realizan alguna peticin.

Mecanismos de sincronizacin entre procesos

Reloj fsico. La idea es proveer de un nico bloque de tiempo para el sistema. Los
procesos pueden usar la marca fsica del tiempo (timestamp) provista o leda de un reloj
central para expresar algn orden en el conjunto de acciones que inician. La principal
ventaja de este mecanismo es la simplicidad, aunque existen varios inconvenientes: el
correcto registro del tiempo depende en la posibilidad de recibir correctamente y en todo
momento, el tiempo actual desplegado por el reloj fsico; los errores de transmisin se
convierten en un impedimento para el orden deseado, el grado de exactitud depende de
las constantes puestas en el sistema. Proceso central. Este mecanismo se basa en un
proceso que recibe todas las peticiones de los procesos que sern sincronizados. La
sincronizacin se logra por la exclusin mutua ejecutada por este proceso central. La
ventaja principal de este mecanismo es que se asegura totalmente de la exclusin mutua.
Como desventajas tiene: Requiere tres mensajes por seccin critica.

Si el proceso tiene que tomar su lugar y ejecutar los siguientes pasos: 1) deteccin de
una falla, i el coordinador falla, un nuevo 2) eleccin de un nico y nuevo coordinador y
3) reconstruccin de la cola de peticiones.

Contador de eventos. Un contador de eventos es un objeto abstracto que permite a los

11

procesos controlar directamente el orden de los eventos, en lugar de usar la exclusin

Pgina

mutua. En otras palabras, es un entero que no se decrementar y cuyo valor inicial es

cero. Existen tres primitivas que definen a un contador de eventos: avance(E).
Incrementa el valor del entero E por 1. Se utiliza esta primitiva para serializar la
ocurrencia de un evento asociado directamente con un contador. read(E). Regresa el
valor actual de E. await (E,v). Suspende la llamada al proceso hasta que el valor de E
sea igual a v (no debe cambiar mientras que se suspende el proceso). Puede ser muy
til cuando se desea que un proceso no se ejecute hasta que ocurra algn evento.

Mecanismos de sincronizacin distribuida

El tomar decisiones en un ambiente distribuido implica que los problemas de

sincronizacin son mucho ms complicados, y el problema est en cmo extender un
orden parcial a un ordenamiento total y arbitrario, usndolo en la resolucin de problemas
de sincronizacin.

12
Pgina
Conclusin

La administracin de rplicas es de suma importancia debido a que de esta depende la

fiabilidad de la informacin, el contar con informacin actualizada y a la mano siempre
que se requiera.

13
Pgina