SO

Diseo de Sistemas Distribuidos
Mster en Ciencia y Tecnologa Informtica

Curso 2016-2017
Modelos y algoritmos distribuidos
Flix Garca Carballeira

Grupo de Arquitectura de Computadores
felix.garcia@uc3m.es
Flix Garca Carballeira Sistemas Distribuidos (2016-2017) 1

Principales caractersticas de un sistema
distribuido
Mltiples procesos
Comunicacin y sincronizacin entre procesos mediante paso
de mensajes
Espacio de direcciones de memoria disjuntos
Ausencia de reloj global
Procesos deben interactuar y cooperar para alcanzar un
objetivo comn

Ejemplos
World Wide Web

Servidores de ficheros en red / distribuidos
Aplicaciones bancarias
Redes peer to peer
Sistemas de control de procesos
Redes de sensores
Grid computing


Motivacin: ZooKeeper
Servicio de coordinacin de alto rendimiento para construir

aplicaciones distribuidas
Forma parte del proyecto Apache Hadoop que desarrolla SW
abierto para construir aplicaciones distribuidas, escalables y
fiables
ZooKeeper se puede utilizar para:
q Implementar consenso distribuido
q Eleccin de lder
q Barreras de sincronizacin
q Cerrojos distribuidos
q Configuracin dinmica
q Servicios de gestin de grupos de procesos

ZooKeeper en Hadoop

Por qu es difcil la coordinacin en
sistemas distribuidos?
El emisor no puede saber:
q Si el mensaje fue recibido
q Si el receptor fallo antes o despus de procesar el mensaje
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

Funcionamiento
Datos organizados de forma jerrquica en memoria

Los clientes establcecen una sesin cuando se conectan a
ZooKeerper

Modelo de datos
Znode
q Almacenado en memoria
q Espacio de nombres
jerrquicos
q No estn pensados para
almacenamiento general
(varios KB)
Tipos:
q Normales
q Efmeros
q Secuenciales
Los clientes pueden manipular los
zonodes a travs del API de
ZooKeeper

Tipos de znodes
Efmeros: los znodes creados por un cliente son borrados al

final de la sesin del cliente (o fallo del cliente)
Secuenciales: incrementan un contador aadido al nombre del
znode

Protocolo de pertenencia a un grupo de
procesos

znodes y flag watch
Los clientes puede hacer operaciones de lectura sobre un

znode con el flag watch activado
El servidor notifica (callback) al cliente cuando la informacin
del nodo ha cambiado
Las notificaciones indican el cambio no los nuevos datos

Sesiones
Un cliente se conecta a ZooKeeper e inicia una sesin

Las sesiones tienen asociado un timeout
ZooKeeper considera que un cliente falla si no recibe nada una
vez expirado el timeout
La sesin finaliza cuando el cliente falla o cuando la cierra de
forma explcita

API del cliente
Create(path, data, flags)

Delete(path, version)
Exist(path, watch)
getData(path, watch)
setData(path, data, version)
getChildren(path, watch)
Sync(path)

API del cliente
Create(path, data, flags)

q flags: ephemeral, sequential
Delete(path, version)
Exist(path, watch)
getData(path, watch)
setData(path, data, version)
getChildren(path, watch)
Sync(path)

Cerrojos con ZooKeeper

Servidores
client
client server replica
client
client
server replica

Servidores
client
client read server replica
client
client
server replica

Servidores
client
client write server replica
client propagate & sych
client
server replica
broadcast atmico

Fallos
client
client
client
server replica

Qu ofrece ZooKeeper?
Consistencia secuencial: las actualizaciones de un cliente se

aplican en el orden en el que fueron enviadas en todos los
servidores
Atomicidad: las actualizaciones se realizan de forma atmica
Imagen nica del sistema con independencia del servidor al
que se conecta
Fiabilidad: cuando una actualizacin se completa, perdura

Cmo lo consigue?
Broadcast atmico
Entrega de mensajes fiable, si un mensaje se entrega a un
q
servidor ser entregado a todos

Orden total: si en un servidor un mensaje A se entrega antes
que un mensaje B, entonces en todos los servidores se hace de
igual forma
Orden causal:
Si un mensaje B es enviado despus de que un mensaje A
q
ha sido entregado por el emisor de B, A debe ser ordenado

antes que B
Si un proceso enva C despus de enviar B, C debe
q
ordenarse despus de B
Cmo lo consigue?
El orden total lo consigue con identificadores nicos en los

mensajes (proceso lder)
Algoritmo de eleccin de lder
La consistencia se asegura utilizando Quorums

En qu se basa ZooKeeper?
En algoritmos distribuidos utilizados para:

q Ordenar de eventos
q Entrega causal de mensajes
q Eleccin de un proceso coordinador (lder)
q Consenso distribuido
q

Problemas tpicos en sistemas
distribuidos
Sincronizacin de relojes
Exclusin mutua
Eleccin de lder
Consenso distribuido
Comunicacin en grupos
Gestin de rplicas
Estados globales

Algoritmos distribuidos
Algoritmos que trabajan en sistemas distribuidos

Realizan tareas:
Comunicacin
q
Gestin de datos y de recursos

q
Sincronizacin
q
Consenso
q
Deben trabajar bajo:

Actividades concurrentes en mltiples localizaciones
q
Incertidumbre del tiempo, ordenacin de eventos, .

q
Posibilidad de fallos (procesos, procesadores, redes)

q

Teorema CAP

Modelos de sistemas distribuidos
Modelo sncrono
Relojes sincronizados
q
Entrega de mensajes acotada

q
Tiempo de ejecucin de procesos acotado

q
Modelo asncrono
No hay sincronizacin de relojes
q
Entrega de mensajes no acotada

q
Tiempo de ejecucin de procesos totalmente arbitraria

q
Sistemas parcialmente sncronos

Tiempos acotados pero desconocidos
q

Tipos de pasos de mensajes
Paso de mensajes sncrono

El envo y la recepcin de un mensaje m, ocurren
q
simultneamente
Paso de mensajes asncrono

El envo de un mensaje m y su recepcin no estn acoplados. No
q
tienen porque ocurrir de forma consecutiva

Modelo de sistema distribuido
Modelo de sistema:
Procesos secuenciales {P1, P2, ...Pn} que ejecutan un
q
algoritmo local
Canales de comunicacin
q
Eventos en Pi
Ei = {ei1, ei2, ...ein}
q
Tipos de eventos locales

Internos (cambios en el estado de un proceso)
q
Comunicacin (envo, recepcin)

q
e e e e 01 02 03 04 e05
P0
Diagramas espacio-tiempo
P1
e11 e12 e13

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. C es un conjunto de estados
2. describe las posibles transiciones( C C)
3. I describe los estados iniciales(I C)
El estado de un sistema distribuido, C, se puede describir

como
q La configuracin actual de cada proceso/procesador
q Los mensajes en trnsito por la red

Configuraciones y estados
En el sistema de transicin de estados del sistema distribuido

q Los estados se denominan configuraciones
q Las transiciones se denominan transiciones de configuracin
En el sistema de transicin de estados de cada proceso

q Los estados se denominan estados
q Las transiciones se denominan eventos
Una ejecucin en un sistema distribuido es una secuencia de

configuraciones (g1, g2, g3, ) donde:
g1 es una configuracin inicial,
q
Hay una transicin entre gigi+1 para todo i 1

q
La secuencia puede ser finita o infinita

q
Una ejecucin o secuencia de estados define el comportamiento del

sistema
Historia de un sistema distribuido

Algoritmos locales
Algoritmo local:
Un proceso cambia de un estado a otro (evento inerno)
q
Un proceso cambia de un estado a otro y enva un mensaje a otro

q
proceso (evento de envo)

Un proceso recibe un mensaje y cambia su estado (evento de
q
recepcin)
Restricciones
Un proceso p solo puede recibir un mensaje despus de
q
haber sido enviado por otro

Un proceso p solo puede cambiar del estado c al estado d si
q
est actualmente en el estado c

Orden causal
La relacin H sobre eventos de una ejecucin distribuida, denominada

orden causal, se define como:
q Si e ocurre antes que f en el mismo proceso, entonces e H f
q Si s es un evento de envo y r su correspondiente evento de recepcin,

entonces s H r
q H Es transitiva
Si a H b y b H c entonces a H c
q H es reflexiva.
a H a para cualquier evento
Dos eventos , a y b, son concurrentes sii a H b y b H a

Ejemplos de eventos
Eventos concurrentes Eventos relacionados

causalmente
p1
p2
p3
time
Eventos relacionados
causalmente

Ejecuciones equivalentes
Dos ejecuciones distribuidas F y E son equivalentes (F~E )

si:
q Tienen el mismo conjunto de eventos
q Se mantiene el orden causal

Ejemplos de ejecuciones equivalentes
p1
Mismo color ~ orden causal
p2
p3
tiempo
p1
p2
p3
tiempo
p1
p2
p3
tiempo

Algoritmos distribuidos
Los algoritmos distribuidos deben tener las siguientes

propiedades:
q La informacin relevante se distribuye entre varias
mquinas
q Los procesos toman las decisiones slo en base a la
informacin local
q Debe evitarse un punto nico de fallo
q No existe un reloj comn

Ejemplos de algoritmos distribuidos
ordenacin de eventos
Exclusin mutua distribuida
Algoritmos de eleccin
Comunicacin multicast y ordenacin de mensajes
Problemas de consenso
Deteccin de interbloqueos
Asignacin de recursos
Planificacin
Tolerancia a fallos

Ordenacin de eventos
Monitorizacin del comportamiento de una aplicacin distribuida

q Ejemplo: el observador debe ordenar los eventos de recepcin de
mensajes en los procesos P1 y P2
e1, e2, e3, e4, e5
P1
m1 m3 m4
m2 m5
P2
Observador
e1 e2 e3 e4 e5

Ejemplo
Monitorizacin del comportamiento de una aplicacin distribuida

q El observador debe ordenar los eventos de recepcin de mensajes en los
procesos P1 y P2
e1, e2, e3, e4, e5
P1
m1 m3 m4
m2 m5
P2
Observador
e1 e2 e3 e4 e5
Para ordenar eventos podemos asignarles marcas de tiempo

ei ek MT(ei) < MT (ek )

Marcas de tiempo en el observador?
P1
m1
m2
P2
Observador
e2 e1
?
Marcas de tiempo en de los procesos?
1 3
P1
m1
m2
6 8
P2
Observador
e1-6 e2-3
?
Marcas de tiempo en de los procesos?
1 3
P1
m1
m2
6 8
P2
Observador
e1-6 e2-3
Los relojes deben estar sincronizados

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)
q
Ci(t): valor del reloj SW (generado por el SO)

q
Ci(t) = a Hi(t) + b
q Ej: # ms o ns transcurridos desde una fecha de referencia
Resolucin del reloj: periodo entre actualizaciones de Ci(t)
q Determina la ordenacin de eventos
Dos relojes en dos computadores diferentes dan medidas
distintas
q Un reloj actual puede tener una deriva de1s al da
q 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
q
Los relojes se consideran sincronizados dentro de D

q
Sincronizacin interna entre los relojes de los computadores de

un sistema distribuido
Los relojes estn sincronizados si |Ci(t) - Cj(t)| < D
q
Dados dos eventos de dos computadores se puede establecer

q
su orden en funcin de sus relojes si estn sincronizados

Sincronizacin externa sincronizacin interna

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 m3 m4
m2 m5
P2
Observador
e1 e2 e3 e4 e5

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
q
Si j < k entonces eij eik

q
Si ei=send(m) y ej=receive(m), entonces ei ej

q
La relacin es transitiva
q
Dos eventos son concurrentes (a || b) si no se puede deducir

entre ellos una relacin de causalidad potencial

Aplicacin de los relojes lgicos
Sincronizacin de relojes lgicos

Depuracin distribuida
Registro de estados globales
Monitorizacin
Entrega causal
Actualizacin de rplicas

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)

Ejemplo
p1
0 1 2 3 4
p2
0 4 5
p3
0 1 6
tiempo

Relojes lgicos totalmente ordenados
Los relojes lgicos de Lamport imponen slo una relacin de

orden parcial:
q 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
q (Ta, Pa): marca de tiempo del evento a del proceso P
(Ta, Pa) < (Tb, Pb) s y solo si
q Ta < Tb o
q Ta=Tb y Pa<Pb

Algoritmo de Welch
Qu ocurre si el sistema ya dispone de un reloj?

No se puede cambiar el valor del reloj si es mantenido por
q
un algoritmo diferente
Algoritmo de Welch
En lugar de avanzar el reloj en respuesta a los mensajes que
q
llegan, se retrasa la entrega de esos mensajes hasta que se

alcanza el valor de tiempo
Los mensajes que llegan se almacenan en un buffer FIFO si
q
su marca de tiempo es menor que la marca de tiempo del

proceso receptor

Problemas de los relojes lgicos
No bastan para caracterizar la causalidad

q 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:

q a H b si y slo si F(a) < F(b)
q Los relojes vectoriales permiten representar de forma
precisa la relacin de causalidad potencial

Problemas de los relojes lgicos
e11 e12
P1
(1) (2)
e21 e22
P2
(1) (3)
e31 e32 e33

P3
(1) (2) (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
q Inicialmente RVi= 0 " i
q Cuando un proceso i genera un evento
RVi[i ] = RVi[i ] +1
q Todos los mensajes llevan el RV del envo
q Cuando un proceso j recibe un mensaje con RV
RVj = max(RVj , RV ) (componente a componente)
RVj[j ] = RVj[j ] +1 (evento de recepcin)

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

Propiedades de los relojes vectoriales
RV < RV si y solo si
RV RV y
q
RV[i ] RV[i ], " i

q
Dados dos eventos a y b

a H b si y solo si RV(a) < RV(b)
q
a y b son concurrentes cuando

q
Ni RV(a) RV(b)[i ] ni RV(b ) RV(b)

Entrega causal
Se distinguen los eventos recibir y entregar

Entrega FIFO
sendi(m) H sendi(m) entonces entregak(m) H entregak(m)
q
Entrega causal
sendi(m) H sendj(m) entonces entregak(m) H entregak(m)
q
La entrega causal requiere retrasar la entrega de un mensaje a un

proceso hasta estar seguros que entre dos envos no hay uno
intermedio
Se puede implementar con relojes vectoriales

Ejemplo de entrega no causal
P1
m
P2
m
P3
send(m) H send(m) pero en P3 se recibe antes m

Exclusin mutua distribuida
Los procesos ejecutan el siguiente fragmento de cdigo

entrada()
SECCIN CRTICA
salida()
Requisitos para resolver el problema de la seccin crtica
Exclusin mutua
q
Progreso
q
Espera acotada
q
Algoritmos
Algoritmo centralizado
q
Algoritmo distribuido
q
Anillo con testigo

q
..
q

Algoritmo centralizado
0 1 2 0 1 2 0 1 2
entrada salida
entrada OK
OK No hay respuespuesta
(bloquea al cliente)
C C C

Algoritmo distribuido de Ricart y
Agrawala
} Algoritmo de Ricart y Agrawala requiere la existencia un
orden total de todos los mensajes en el sistema
} Un proceso que quiere entrar en una seccin crtica (SC) enva
un mensaje a todos los procesos (y a l mismo) con una marca
de tiempo lgica
} Cuando un proceso recibe un mensaje
Si el receptor no est en la SC ni quiere entrar enva OK al
}
emisor
Si el receptor ya est en la SC no responde
}
Si el receptor desea entrar, compara la marca de tiempo del

}
mensaje. Si el mensaje tiene una marca menor enva OK. En

caso contrario entra y no enva nada.
} Cuando un proceso recibe todos los mensajes puede entrar
Ejemplo
a) Dos procesos (P0, P2) quieren entrar en la regin al mismo
tiempo
b) El proceso 0 tiene la marca de tiempo ms baja, entra l.
c) Cuando el proceso 0 acaba, enva un OK, de esa forma el
proceso 2 entra
64
Flix Garca Carballeira Sistemas Distribuidos (2016-2017)
Anillo con testigo
Los procesos se ordenan conceptualmente como un anillo
Por el anillo circula un testigo
Cuando un proceso quiere entrar en la SC debe esperar a
recoger el testigo
Cuando sale de la SC enva el testigo al nuevo proceso del
anillo
65
Ejemplo. Algoritmo de votacin de
Maekawa
Idea: no solicitar permiso de todos los procesos, solo de un
subconjunto
Los subconjuntos deben solaparse
q
A cada proceso Pi se le asocia un conjunto de votantes

{ Vi | i = 1, , N }
q
Pi est en Vi
Vi Vj
Todos subconjuntos de igual tamao
Cada proceso Pj est contenido en M subconjutos
votantes
Solucin optima
K~ N
q
M=K
q
Algoritmo de votacin de Maekawa
enter():
state := WANTED;
Multicast request to processes in Vi - { Pi };
Wait until (K - 1) responses are received;
state := HELD;
When Pj receives a request from Pi, i j:

if(state == HELD or voted == TRUE) {
Queue request without responding;
} else {
Reply to Pi;
voted := TRUE;
}

Algoritmo de votacin de Maekawa
release():
state :=RELEASED;
Multicast release to processes in Vi - { Pi };
When Pj receives a release msg from Pi i j:

if(request queue == EMPTY) {
voted := FALSE;
} else {
Remove head of queue, P(k);
Reply to process P(k);
voted := TRUE;
}

Cerrojos en ZooKeeper

til en aplicaciones donde es necesario la existencia de un
coordinador
Varios procesos necesitan elegir un lder/coordinador
q
Por ejemplo, en una red token ring, cuando el testigo se pierde

q
En ZooKeeper cuando el coordinador falla

q
El algoritmo debe ejecutarse cuando falla el coordinador

Algoritmo del matn
q
Algoritmo de anillo
q
El objetivo de los algoritmos es que la eleccin sea nica aunque el

algoritmo se inicie de forma concurrente en varios procesos
70
Variantes del problema
Comunicacin sncrona o asncrona?

Cmo estn conectados los procesos?
En anillo, completamente conectados,
q
El nmero de procesos es conocido?

Los procesos tienen un identificador nico?

Eleccin de lder con ZooKeeper

Algoritmo del mton
Suposiciones:
q Comunicacin sncrona
q Procesos completamente conectados
q Entrega de mensajes fiable

Algoritmo del matn. Ejemplo
} Utiliza timeouts (T) para detectar fallos
} Asume que cada proceso conoce qu procesos tiene ID
mayores
} 3 tipos de mensajes:
n coordinador: anuncio a todos los procesos con IDs menores
n eleccin: enviado a procesos con IDs mayores
n OK: respuesta a eleccin
} Si no se recibe dentro de T, el emisor de eleccin enva
coordinador
} En caso contrario, el proceso espera durante T a recibir un
mensaje coordinador. Si no llega comienza una nueva
eleccin
74
Cuando un proceso P observa que el coordinador no responde
inicia una eleccin:
a) Proceso 4 enva eleccin

b) Proceso 5 y 6 responden, dicindole que pare
c) Ahora 5 y 6 comienzan la eleccin
75
d) Proceso 6 dice a 5 que pare

e) Proceso 6 indica a todos que es el coordinador
76
Algoritmo LCR (basado en anillo)
Algoritmo LeLarnn, Chang y Roberts

Suposiciones:
q Comunicacin sncrona
q Procesos en anillo
q Identificador nico para cada proceso
q Tamao de la red desconocida

Algoritmo del anillo
Cualquier proceso puede comenzar la eleccin y enva un
mensaje de eleccin a su vecino con su identificador y se
marca como participante
Cuando un proceso recibe un mensaje de eleccin compara el
identificador del mensaje con el suyo:
q Si es mayor reenva el mensaje al siguiente
q Si es menor y no es un participante sustituye el identificador del
mensaje por el suyo y lo reenva.
q Si es menor y es un participante no lo reenva
q Cuando se reenva un mensaje el proceso se marca como participante
Cuando un proceso recibe un identificador con su nmero y es
el mayor se elige como coordinador
El coordinador notifica al resto

Algoritmo del anillo
El 2 y el 5 generan mensajes de eleccin y lo envan al siguiente
Se elige como coordinador el proceso que recibe un mensaje con su n y es
el mayor
Este proceso a continuacin enva mensajes a todos informando que es el
coordinador
1 2 2
6
0 3
7 4
6 5
5
79
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.

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:
q Replicando datos.
q Cuando se cambia un dato, el nuevo valor se enva a todos los
procesos que gestionan las rplicas.

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.

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
q
dos bases de datos.

Al mismo tiempo se paga un 10% de intereses, enviando un
q
multicast a las dos bases de datos.

Qu ocurre si los mensajes llegan en diferente a orden a las
q
dos bases de datos?

Implementacin del multicast
Implementacin de operaciones multicast:

q Mediante operaciones punto a punto.
q Mecanismo poco fiable.
Problemas de fiabilidad:
q Alguno de los mensajes se puede perder.
q El proceso emisor puede fallar despus de realizados
algunos envos. En este caso algunos procesos no recibirn
el mensaje.

Multicast fiable
Se enva un mensaje a todos los procesos y se espera confirmacin

de todos.
Si todos confirman el multicast se ha completado.
q
Si alguno no confirma se retransmite. Si no enva confirmacin

q
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
q
receptores debe completar el envo a todos los dems.

Cuando un proceso recibe un mensaje lo enva al resto
Cuando un proceso recibe un mensaje enva una confirmacin y
monitoriza al emisor para ver si falla. Si falla completa el multicast.
En cualquier caso hay que descartar los mensajes duplicados

Ejemplo de multicast sin ordenacin
P1 P2 P3 P4
A B
Tiempo
A B

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
t2
t1
tiempo
c1
c2 c3
FE1 GR1 GR2 GR3 FE2

Problemas en servidores georeplicados

Tipos de anomalas que no siguen orden
causal (1)

causal (2)

causal (3)

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
q
Progreso: todos los mensajes se entregan

q
entrega
cola de cola de
espera entrega
Peticiones

Implementacin de la ordenacin total
} Se asigna a cada peticin un identificador de orden total
(IOT)
} Este identificador se utiliza para entregar los mensajes en el
mismo orden a todos los procesos
} Mtodo centralizado:
q Se utiliza un proceso secuenciador encargado de asignar
IOT a los mensajes
q Cada mensaje se envan al secuenciador
} El secuenciador incrementa IOT
} El secuenciador le asigna un IOT y lo enva a los procesos
q Cuando un proceso recibe un mensaje con un IOT mayor
del esperado, pide al secuenciador que le enve de nuevo el
mensaje
q Posible cuello de botella y punto de fallo crtico
94
Mtodo distribuido
Birman y Joseph 1987
Cada proceso q en el grupo almacena:
q Aq: mayor nmero de secuencia acordado que se ha observado hasta el
momento
q Pq: su mayor nmero de secuencia propuesto
q Los identificadores deben incluir el nmero de proceso para asegurar un orden
total
Cuando un proceso p realiza un BCAST enva el mensaje al resto
Cada proceso q que recibe el mensaje de p
q Propone Pq=Max(Aq, Pq) + 1
q Almacena (m, Pq) en su cola y lo marca como no entregable
q Enva Pq al emisor del mensaje (p)
El proceso q recibe todos los nmeros de secuencia propuesto y selecciona el mayor
A como el siguiente nmero de secuencia acordado y lo enva a todos
q En q se fija Aq = Max(Aq, A) y se marca el mensaje como entregable
q Se reordena la cola y si est el primero se entrega
95
Ejemplo
Nodo 1 Nodo 2 Nodo 3
A1 = 14 A12 = 15 A3 = 16
Multicast (M1) Multicast(M2) Multicast(M3)
Inicialmente:
Los tres nodos realizan un multicast simultneo

Ejemplo
A1 = 14 A12 = 15 A3 = 16
Inicialmente:
Los tres nodos realizan un multicast simultneo

Ejemplo
A1 = 14 A12 = 15 A3 = 16
M3 M1 M2 M2 M1 M3 M1 M3 M2
15.1 16.1 17.1 16.2 17.2 18.2 17.3 18.3 19.3
U U U U U U U U U
Etapa 1:
Los mensajes llegan a los receptores en orden distinto
Se les propone un nmero de secuencia, Pq=Max(Aq, Pq) + 1
(se aade identificador de proceso)
Se insertan en las colas y se marcan como no entregables (U)

Ejemplo
A1 = 14 A12 = 15 A3 = 16
M3 M1 M2 M2 M1 M3 M1 M3 M2
15.1 17.3 17.1 16.2 17.3 18.2 17.3 18.3 19.3
U U U U U U U U U
Etapa 2:
El Nodo 1 recibe las marcas asociada a M1 envidas por el nodo 2 (17.2) y 3 (17.3)
y calcula el mximo de las tres, y se las enva al resto (17.3)

Ejemplo
A1 = 14 A12 = 15 A3 = 16
M3 M2 M1 M2 M1 M3 M1 M3 M2
15.1 17.1 17.3 16.2 17.3 18.2 17.3 18.3 19.3
U U D U D U D U U
Etapa 2:
Se marca M1 como entregable y se reordenan las colas
M1 se puede entregar en el nodo 3 porque ser el primero de la cola

Ejemplo
A1 = 14 A12 = 15 A3 = 16
M3 M2 M1 M2 M1 M3 M3 M2
15.1 17.1 17.3 16.2 17.3 18.2 18.3 19.3
U U D U D U U U
Etapa 2:
M1 se entrega en el nodo 3

Ejemplo
A1 = 14 A12 = 15 A3 = 16
M3 M2 M1 M2 M1 M3 M3 M2
15.1 17.1 17.3 16.2 17.3 18.2 18.3 19.3
U U D U D U U U
Etapa 3:
El Nodo 2 recibe las marcas asociada a M2 envidas por el nodo 1 (17.1) y 3 (19.3) ,
Calcula el mximo (19.3)

Ejemplo
A1 = 14 A12 = 15 A3 = 16
M3 M2 M1 M2 M1 M3 M3 M2
15.1 19.3 17.3 19.3 17.3 18.2 18.3 19.3
U U D U D U U U
Etapa 3:
El Nodo 2 recibe las marcas asociada a M2 envidas por el nodo 1 (17.1) y 3 (19.3) ,
Calcula el mximo (19.3)
Se la enva al resto

Ejemplo
A1 = 14 A12 = 15 A3 = 16
M3 M1 M2 M1 M3 M2 M3 M2
15.1 17.3 19.3 17.3 18.2 19.3 18.3 19.3
U D D D U D U D
Etapa 3:
M2 se marca como entregable y se reordenan las colas

Ejemplo
A1 = 14 A12 = 15 A3 = 16
M3 M1 M2 M3 M2 M3 M2
15.1 17.3 19.2 18.2 19.3 18.3 19.3
U D D U D U D
Etapa 3:
M2 se marca como entregable y se reordenan las colas
M1 se entrega en el nodo 2

Ejemplo
A1 = 14 A12 = 15 A3 = 16
M3 M1 M2 M3 M2 M3 M2
15.1 17.3 19.2 18.2 19.3 18.3 19.3
U D D U D U D
Etapa 4:
Calcula el mximo de todas (18.3)

Ejemplo
A1 = 14 A12 = 15 A3 = 16
M3 M1 M2 M3 M2 M3 M2
18.3 17.3 19.2 18.3 19.3 18.3 19.3
U D D U D U D
Etapa 4:
Calcula el mximo de todas (18.3)
Se las enva al resto

Ejemplo
A1 = 14 A12 = 15 A3 = 16
M1 M3 M2 M3 M2 M3 M2
17.3 18.3 19.2 18.3 19.3 18.3 19.3
D D D D D D D
Etapa 4:
Se marca M3 como entregable y se reordenan las colas
Se pueden entregar todos los mensajes en todos los nodos
El orden de entrega: M1, M3 y M2 (se asegura el orden de entrega en todos los nodos)

Implementacin de la ordenacin causal
} Cada proceso pi, almacena un vector VT con n componentes
} En el proceso pj, la componente i indica el ltimo mensaje
recibido de i
} Algoritmo para actualizar el vector
q Todos los procesos inicializan el vector a 0
q Cuando pi enva un nuevo mensaje incrementa VTi(i) en 1 y
aade VT al mensaje
} Cuando a pj le llega un mensaje de pi con VT se entrega si:
q VT(i) = VTj(i) + 1 (siguiente en la secuencia de pi)
q VT(k) VTj(k) para todo k i (todos los mensajes
anteriores se han entregado a i)
} Cuando un mensaje con VT se entrega a pj se actualiza su
vector:
} VTj = max(VTj, VT), para k=1, 2, ... , n
109
Ejemplo
(0,0,0) (0,1,0) (0,1,1)

P0
(0,0,0) (0,1,0)
P1
(0,1,1)
(0,0,0)
P2
(0,1,0) (0,1,1)
110
Ejemplo
Vector enviado por el proceso 0: (4, 6, 8, 2, 1, 5)
Vector en el proceso 1: (3, 7, 8, 2, 1, 5)
Se puede entregar el mensaje enviado por el 0?
111
Ejemplo
Vector enviado por el proceso 0: (4, 6, 8, 2, 1, 5)
Se puede entregar el mensaje enviado por el 0?
q Al 1 si:
Es el siguiente en la secuencia de mensajes recibidos del 0 y
no se han perdido mensajes.
q Al 2 no:
Es el siguiente en la secuencia de mensajes recibidos del 0.
Le falta un mensaje del proceso 1
112
Problemas de consenso
Objetivo: que un conjunto de procesos se pongan de acuerdo en una

determinada accin o valor.
Un servicio de consenso consta de
Un conjunto de N procesos que deben tener una visin
q
consensuada de un determinado objeto, valor o accin

Clientes que envan peticiones a los procesos para proponer un
q
valor
Objetivo: que el conjunto de procesos consensuen un valor
q
Un protocolo de consenso es correcto sii:

Todos los nodos deciden el mismo valor (seguridad)
q
El valor decidido debe haber sido propuesto por algn nodo

q
Todos los nodos deciden el valor en el algn momento

q
(terminacin)
Aplicaciones
Transacciones distribuidas
En grupos de procesos
Eleccin de lder
Servidores replicados

Two-phase-commit
Two-phase-commit (2PC), Jim Gray (1970)

Denominamos coordinador al proceso que realiza la operacin
Coordinador: P0 P1 P2
multicast: ok to commit? OK to commit
recoger las respuestas

todos ok => send(commit) Grabar en
rea temporal
else => send(abort)
Procesos: ok
ok to commit=> guardar
la peticin en un
Commit! Hacer los cambios
rea temporal y responder ok permanentes
commit => hacer los cambios

permanentes
abort => borrar los datos temporales

Ejemplo
ok to
commit?

Ejemplo
ok to
commit?
ok

Ejemplo
ok to
commit?
commit ok
Hacer los
cambios
permanentes

Modos de fallo en sistemas distribuidos
Fallo parada (fail stop): el nodo que falla no se recupera

Fallo por omisin: fallo que causa que un componente no
responda en algunas ocasiones
Fallo con recuperacin (fail recover): un componente falla,
pero continua su ejecucin sin fallo posteriormente
Fallos de tiempo: el componente responde demasiado tarde, no
se cumple el rendimiento esperado, ..
Fallos bizantinos: funcionamiento arbitrario

Posibles fallos en 2PC
Alguno de los procesos (coordinador, participantes) falla

durante el protocolo
Se pierde alguno de los mensajes del protocolo
Para hacer frente a los fallos (no bizantinos):
Cada proceso almacena la informacin del protocolo en
q
almacenamiento persistente
Cuando el proceso se recupera recupera la informacin
previamente guardada
q Se utilizan timeouts para evitar los bloqueos en el protocolo

Ejemplo con fallo en la respuesta
Coordinador A B C
ok to
commit?
ok Proceso falla

Ejemplo con fallo en la respuesta
Coordinador A B C
ok to
commit?
ok Proceso falla
timeout

Ejemplo con fallo respuesta
Coordinador A B C
ok to
commit?
ok Proceso falla
abort

Fallo en el coordinador
Coordinador A B C
ok to
commit?
ok
commit

Fallo en el coordinador
El proceso C puede enviar un mensaje al coordinador

pidindole la decisin
Si la recibe OK
q
Si no la recibe tiene que esperar a que el coordinador se

q
recupere
El proceso C puede solicitar la decisin a alguno de los otros
participantes

Acciones despus de una recuperacin
Si fall el coordinador, cuando reinicia:

Si el estado fue commit entonces enva commit
q
Si en estado fue abort entonces enva abort

q
Si fall un proceso, cuando reinicia:

Si no encontr ok aborta la operacin
q
Si encontr ok, ejecuta el protocolo de terminacin para

q
decidir

Fallos de bloqueo del protocolo 2PC
El coordinador enva una peticin ok to commit a A, B, C y D

Todos responden ok
El coordinador enva commit a A y a continuacin el
coordinador y A fallan
B, C y D han respondido ok pero no reciben commit ni del
coordinador ni de A

Imposibilidad de consenso
En un sistema sncrono es posible

En un sistema asncrono es imposible
q 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
Por qu?
q 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
En sistemas sncronos 3PC asegura seguridad y terminacin
2PC no asegura terminacin
Three-phase commit
coordinador participantes (A, B, C )
canCommit?
yes Fase 1
prepareCommit
Fase 2
ACK
doCommit
haveCommitted Fase 3
Dale Skeen el al. (1980)

Resuelve el problema de bloqueo?
Asumir que el coordinador y A fallan en la fase 3 justo

despus del doCoomit a A
Si alguno de los procesos restantes ha recibido prepareCommit
puede terminar el protocolo
Si ninguno ha recibido prepareCommit, abortan

Empleo de timeouts
coordinador participantes (A, B, C )
canCommit?
yes Fase 1
prepareCommit Timeout -> abortar

Fase 2
Timeout -> abortar ACK
doCommit Timeout -> commit

haveCommitted Fase 3
Timeout -> abortar

Particiones de red
2PC y 3PC no funcionan en caso de particiones de red

A recibe prepareCommit del coordinador
Ocurre una particin de A con el resto
El resto de participantes no recibe
prepareCommit y abortan
A est preparado para commit, de
acuerdo al protocolo, decide commit
de forma unilateral

Consenso basado en quorums
Se definen dos operaciones READ y WRITE

Hay un conjunto de N nodos, que sirven peticiones
q Un READ debe realizarse sobre R copias
q Un WRITE debe realizarse sobre W copias
q Cada rplica tiene un nmero de versin V
q Debe cumplirse que:
R+W>N
W+W>N
R, W < N

Mtodo de votacin
READ
Se lee de R rplicas, se queda con la copia con la ltima
q
versin
WRITE
Hay que asegurarse que todas las rplicas se comportan
q
como una sola (seriabilidad)

Se realiza en primer lugar una operacin READ para
q
determinar el nmero de versin actual.

Se calcula el nuevo nmero de versin.
q
Se inicia un 2PC para actualizar el valor y el nmero de

q
versin en W o ms rplicas.

Votacin jerrquica
El problema de los esquemas basados en quorum es que W

aumenta al aumentar el nmero de rplicas
Solucin: quorum jerrquico
Ej: nmero de rplicas = 5 x 5 = 25 (nodos hoja)
q

Votacin jerrquica
El quorum se realiza por niveles
R1W1 R2 W2 RT WT
1 5 1 5 1 25
1 5 2 4 2 20
1 5 3 3 3 15
2 4 2 4 4 16
2 4 3 3 6 12
3 3 3 3 9 9
Cul se elige?
Replicacin de datos utilizando 2PC
Sea un conjunto de procesos {P0, P1,...,Pn} que mantienen una rplica sobre
las que se hacen operaciones readi, updatei
Objetivo: definir dos operaciones distribuidas READ y UPDATE que son
disponibles incluso cuanto t < n procesos fallan y devuelven fallos
indistinguibles de aquellos que no fallan.
Se denota como qr el nmero de rplicas que deben leerse para una
operacin READ
Se denota como qu el nmero de rplicas que deben actualizarse para un
UPDATE.
Para utilizar esquemas basados en quorum se necesita:
q qr + qu > n
q qu+qu > n

Para tolerar t fallos, ser necesario que

q qu no sea mayor que n-t
q r>t
Se asocia un nmero de versin a cada dato. El nmero de versin se
incrementa en cada actualizacin.
READ: el proceso lee qr rplicas y descarta las rplicas con nmeros
pequeos. El resto deben ser idnticos y se utilizar como valor ledo.
UPDATE: utiliza el protocolo 2PC
q Se realiza en primer lugar una operacin READ para determinar el
nmero de versin actual.
q Se calcula el nuevo nmero de versin.
q Se inicia un 2PC para escribir el valor y el n de versin en qu o ms
rplicas.

UPDATE (Continuacin)
q Una rplica indica abortar si ella tiene un n de versin
mayor
q En caso contrario bloquea las READ y espera en ok to
commit
q El coordinador comprometer el resultado si slo recibe
mensajes commit de al menos qu rplicas. En caso contrario
aborta.
q Las operaciones READ se retrasan durante el estado ok to
commit.
q Si llegan operaciones UPDATE en ok to commit las aborta

Paxos
Leslie Lamport (1989)

Protocolo para alcanzar consenso basado en mquinas de
estado finito (asegura seguridad y terminacin)
Todos los nodos alcanzan consenso a pesar de fallos en los
nodos, particiones de red y retrasos en la entrega de mensajes

Aplicacin de Paxos
Google: Chubby (servicio de cerrojos distribuido basado en

Paxos)
Bigtable y otros servicios de Google utilizan Chubby
q
Yahho: ZooKeeper (servicio de cerrojos distribuido basado en

Paxos)

Propiedades de Paxos
Seguridad: si se alcanza consenso, todos los nodos acuerdan el

mismo valor
Tolerancia a fallos: si menos de la mitad de los nodos fallan, el
resto alcanza acuerdo
Terminacin no garantizada en casos muy improbables en el
mundo real

Idea bsica
Similar a 2PC pero con dos procesos (proposer, aceptors)

Uno o ms nodos deciden ser coordinador (proposer)
El nodo proposer propone un valor y solicita la aceptacin de
un conjunto de nodos aceptors
El nodo proposer anuncia el valor elegido o lo intenta de
nuevo sino se ha alcanzado un valor

Idea bsica


Idea bsica

Cualquier nodo puede
proponer/(aceptar

Mecanismos utilizados en Paxos
Las propuestas van ordenadas con un nmero de propuesta

nico
2PC necesita que todos los nodos acuerden el valor
Paxos solo necesita la mitad + 1 de los nodos para alcanzar
consenso
Permite que el sistema siga funcionando en presencia de
q
fallos
Resuelve los problemas de particin (no puede haber dos
q
mayoras simultneamente)

Funcionamiento
Cada proposer propone un valor a todos los nodos accpetors

Cada acceptor acepta el primer valor propuesto que recibe y
rechaza el resto
Si el proposer recibe respuestas positivas de una mayora,
elige ese valor
El nodo proposer enva el valor elegido a todos los nodos
Todas las propuestas llevan un orden global

Ordenacin de las propuestas
Cada aceptor debe ser capaz de aceptar mltiples propuestas

Cada propuesta lleva asociada un nmero de orden global que
utilizan los nodos acceptors para aceptar/rechazar
Ej: (direccin de nodo:nmero de secuencia local)
q
Reglas para aceptar propuestas:

Cuando un nodo acceptor recibe una nueva propuesta con
q
nmero N, lo compara con el nmero de propuesta M ya

aceptada
Si N > M acepta la nueva propuesta, en caso contrario la
rechaza
q Si el acceptor decide aceptar la nueva propuesta N, le pide
al proposer que utilice el mismo valor de la propuesta M
Protocolo detallado
Cada nodo almacena:

q (Na. Va): propuesta con nmero ms alta y su valor
q Nh: nmero de propuesta ms alto visto
q N: nmero de propuesta actual

Fase 1
Fase 1 (Propuesta):
q Un nodo decide hacer una propuesta (lder)
q Elige N > Nh
q Enva (propuesta, N) a todos los nodos
q Cuando se recibe (propuesta, N)
IF (N < Nh)
Responder rechazar
ELSE
Nh = N
Responder (propuesta-OK, Na, Va)
No aceptar ninguna propuesta futura con valor < N

Fase 2
Fase 2 (Aeptar):
q IF el lider obtiene una mayora de OK
V = valor del Na recibido ms alto
IF (V = null) el lider elige cualquier valor V
Enva (aceptar, N, -V) a todos los nodos
q IF el lider no obtiene mayora
Espera y reinicia el protocolo
q Cuando un nodo recibe (aceptar, N, V)
IF (N < Nh)
Responde con rechazar
ELSE
Na = N; Va = V; Nh=N
Responder OK

Fase 3
Fase 3 (decidir)
q Si el lider recibe OK de una mayora
Enva (decidir, Va) a todos los nodos
q Sino espera (aleatoriamente) y reinicia el protocolo

Ejemplo

Acuerdo bizantino
En la mayora de las ocasiones cuando un componente o

sistema falla, su funcionamiento es arbitrario.
Pueden enviar informacin diferente a diferentes
q
componentes con los que se comunica.

Alcanzar un acuerdo entre las observaciones que hacen
q
diferentes componentes puede ser complicado en presencia

de fallos.
El objetivo con acuerdo bizantino es alcanzar un acuerdo
sobre un determinado valor en un sistema donde los
componentes pueden fallar de forma arbitraria.
Importancia:
Permite enmascarar fallos arbitrarios.
q
Permite construir procesadores con fallos de tipo fallo-

q
parada
Definicin del problema
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
q
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 con tres nodos
Utilizando tres nodos, si uno falla el problema no puede

resolverse.
Se necesitan 3m+1 nodos para hacer frente a m fallos
bizantinos.
1 emisor
1
nodo i 0
nodo j
1 emisor
0
nodo i 0
nodo j

Solucin para cuatro nodos
} Suposiciones:
Los mensajes enviados se entregan correctamente.
}
El receptor conoce al emisor de un mensaje

}
Se puede detectar la ausencia de un mensaje

}
} Algoritmo (Lamport, Pease y Shostack) para cuatro nodos:

Se basa en el intercambio de mensajes entre los nodos
}
Cada nodo Ni realiza la observacin Oi

}
Cada nodo mantiene un vector V con informacin recibida de los

}
otros nodos. Vi(j) almacena el valor recibido de Nj

Inicialmente Vi(i) = Oi y Vi(j) = null (" i j)
}
Cada nodo enva un mensaje al resto indicando su observacin.

}
Cuando un nodo recibe una observacin actualiza su vector y

}
enva a los otros dos nodos la observacin recibida.

Solucin
Despus del intercambio de mensajes, cada nodo construye un
vector con los valores mayoritarios
Si no existe mayora entonces se asume que no hay un
observacin coherente.

Ejemplo. Etapa inicial
Nodo 1
* * * *
Nodo 4 Nodo 2
* * * E * A * *
Nodo 3
* * A *

Ejemplo. Primer intercambio de mensajes
Nodo 1
* * * *
Nodo 4 Nodo 2
E A A E R A A E
Nodo 3
R A A E
V3(1) V3(2) V3(3) V3(4)

Ejemplo. Segundo intercambio de mensajes
Nodo 1
* * * *
Nodo 4 Nodo 2
E A A E V4(j) V2(j) R A A E
R E V1(j) V1(j) R R
V2(j)
Nodo 3 V3(j)
R A R E
R A A E V3(j)
R A V3(j) V4(j) E A
E R V1(j)
Vi(1) Vi(2) Vi(3) Vi(4) Vi(1) Vi(2) Vi(3) Vi(4)
R E V2(j)
E A V3(j)
Vi(1) Vi(2) Vi(3) Vi(4)
Vi(j) -> La observacin que de j dice i

Etapa final
Nodo 1 Nodo 2
V2(j) R A A E
* * * *
V1(j) R R
V3(j) R E
V4(j) E A
Nodo 4
Vi(1) Vi(2) Vi(3) Vi(4)
R A A E
Nodo 2
Nodo 3 R A A E
R A A E

El problema del interbloqueo
Situacin en la que cada proceso

est bloqueado en espera de un PA R2
recurso (o evento) que est asignado

a (o slo puede producir)
un proceso (tambin bloqueado) del R1 PB
conjunto
Interbloqueo
Tipos:
De recursos
q
De comunicacin
q

Estrategias
Modelizacin de interbloqueos mediantes grafos

Prevencin de interbloqueos
Evitacin de interbloqueos
Deteccin de interbloqueos

Estados globales consistentes
En un sistema distribuido existen ciertas situaciones que no es

posible determinar de forma exacta por falta de un estado
global:
q Recoleccin de basura: Cuando un objeto deja de ser
referenciado por ningn elemento del sistema.
q Deteccin de interbloqueos: Condiciones de espera cclica
en grafos de espera (wait-for graphs).
q Deteccin de estados de terminacin: El estado de actividad
o espera no es suficiente para determinar la finalizacin de
un proceso.

Definiciones
El estado global de un sistema distribuido se denota por G=(S,L),

donde:
q S={s1, s2, s3, s4,...,sM} : Estado interno de cada uno de los M
procesadores.
q L={Li,j| i,j 1..M} : Li,j Estado de los canales unidireccionales
Ci,j entre los procesadores. El estado del canal son los
mensajes en l encolados
m1 m2 m2 mk
Sj Si
Cij
Lij={m , , m } 1 k

Snapshots
El anlisis de los estados globales de un sistema se realiza por
medio de snapshots: Agregacin del estado local de cada
componente as como de los mensajes actualmente en
transmisin.
Debido a la imposibilidad de determinar el estado global de todo

el sistema en un mismo instante se define una propiedad de
consistencia en la evaluacin de dicho estado.

Cortes consistentes
Un corte es un conjunto de eventos (contiene al menos un

evento por proceso)
Un corte es consistente si para cada evento que contiene,
incluye tambin todos los eventos que le preceden causalmente
Si a y b son dos eventos en un sistema distribuido y C un corte
consistente, entonces:
(a C) (b a) b C
q
Si para un mensaje m, el evento receive(m) C, entonces el

evento send(m) C.

Cortes Consistentes
Corte no consistente Corte consistente
p1 p2 p3 p1 p2 p3
m1 m1
m2 m4 no se m2
ha enviado
m3 m3
m4 ya ha
m4 m4
llegado
m5 m5

Algoritmo de Chandy-Lamport
Algoritmo para determinar un estado global consistente

Supone canales FIFO
Un proceso denominado iniciador comienza el algoritmo de
snapshot distribuido.
Cualquier proceso puede iniciar el algoritmo.
El proceso iniciador enva un mensaje especial denominado
marcador
El estado global consta de los estados de los procesos y de los
canales.
Los canales son pasivos: la responsabilidad de registrar el
q
estado de un canal depende del proceso emisor

Suposiciones
Entre cada par de procesos el canal es FIFO

No hay fallos en los procesos ni en los canales durante la
ejecucin del algoritmo
Cualquier proceso puede iniciar el algoritmo en cualquier
instante
Los procesos pueden seguir enviando y recibiendo los
mensajes de aplicacin durante la ejecucin del algoritmo
Idea: es que cada proceso registre su estado y para cada canal,

todos los mensajes que entraron despus de que l registrata su
estado y antes de que el emisor le enve un mensaje marcador
(lo que supone que ya ha registrado su estado).
Algoritmo
Entre Pi y Pj el canal se denomina Cij
Proceso iniciador (P1) de forma atmica:
q Registra su estado local S1
q P1 enva el marcador a todos sus vecinos a travs de los canales salientes.
q A partir de este momento almacenar en los canales Ck1 los mensajes de
aplicacin que vaya recibiendo
Cuando un proceso Pi recibe un marcador de Pj (iniciador o no):
q Si aun no ha grabado su estado:
Pi graba su estado Si
Graba el estado del canal Cji como vaco. Para el resto de canales se
almacenarn los mensajes de aplicacin a partir de ese momento
Reenva un mensaje marcador al resto de procesos (entre la recepcin del
marcador y su reenvo no ejecuta ningn otro evento).
q Si ya ha grabado su estado:
Se registra el estado del canal Cji como completo
El algoritmo termina para un proceso una vez que ha recibido el marcador de todos
los procesos
Algoritmo
Una vez registrados todos los estados (el algoritmo ha

terminado)
q El estado global consistente puede ensamblarse en cada
proceso haciendo que cada proceso enve los datos del
estado que l ha registrado, por ejemplo, a otro proceso

Ejemplo
saldo inicial saldo inicial
elementos disponibles elementos disponibles
Tipos de mensajes:
(order 10, $100): se piden 10 elementos y se transfiere $100
(5 widgets): se envan 5 elementos

Ejemplo
Qu estado se registra para cada proceso y cada canal?

Ejemplo
Qu estado se registra para cada proceso y cada canal?

Ejercicio
qu estado se registra?

SO

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

SO

Încărcat de

Drepturi de autor:

Formate disponibile

Diseo de Sistemas Distribuidos

Mster en Ciencia y Tecnologa Informtica

Modelos y algoritmos distribuidos

Flix Garca Carballeira

Flix Garca Carballeira Sistemas Distribuidos (2016-2017) 1

Flix Garca Carballeira Sistemas Distribuidos (2016-2017) 2

World Wide Web

Flix Garca Carballeira Sistemas Distribuidos (2016-2017) 3

Servicio de coordinacin de alto rendimiento para construir

Flix Garca Carballeira Sistemas Distribuidos (2016-2017) 4

Flix Garca Carballeira Sistemas Distribuidos (2016-2017) 5

Impossibility of distributed consensus with one faulty

Flix Garca Carballeira Sistemas Distribuidos (2016-2017) 6

Datos organizados de forma jerrquica en memoria

Flix Garca Carballeira Sistemas Distribuidos (2016-2017) 7

Flix Garca Carballeira Sistemas Distribuidos (2016-2017) 8

Efmeros: los znodes creados por un cliente son borrados al

Flix Garca Carballeira Sistemas Distribuidos (2016-2017) 9

Flix Garca Carballeira Sistemas Distribuidos (2016-2017) 10

Los clientes puede hacer operaciones de lectura sobre un

Flix Garca Carballeira Sistemas Distribuidos (2016-2017) 11

Un cliente se conecta a ZooKeeper e inicia una sesin

Flix Garca Carballeira Sistemas Distribuidos (2016-2017) 12

Create(path, data, flags)

Flix Garca Carballeira Sistemas Distribuidos (2016-2017) 13

Create(path, data, flags)

Flix Garca Carballeira Sistemas Distribuidos (2016-2017) 14

Flix Garca Carballeira Sistemas Distribuidos (2016-2017) 15

client server replica

client server replica

Flix Garca Carballeira Sistemas Distribuidos (2016-2017) 16

client read server replica

client server replica

Flix Garca Carballeira Sistemas Distribuidos (2016-2017) 17

client write server replica

client propagate & sych

client server replica

Flix Garca Carballeira Sistemas Distribuidos (2016-2017) 18

client server replica

client server replica

Flix Garca Carballeira Sistemas Distribuidos (2016-2017) 19

Consistencia secuencial: las actualizaciones de un cliente se

Flix Garca Carballeira Sistemas Distribuidos (2016-2017) 20

servidor ser entregado a todos

ha sido entregado por el emisor de B, A debe ser ordenado

El orden total lo consigue con identificadores nicos en los

Flix Garca Carballeira Sistemas Distribuidos (2016-2017) 22

En algoritmos distribuidos utilizados para:

Flix Garca Carballeira Sistemas Distribuidos (2016-2017) 23

Flix Garca Carballeira Sistemas Distribuidos (2016-2017) 24

Algoritmos que trabajan en sistemas distribuidos

Gestin de datos y de recursos

Deben trabajar bajo:

Incertidumbre del tiempo, ordenacin de eventos, .

Posibilidad de fallos (procesos, procesadores, redes)

Flix Garca Carballeira Sistemas Distribuidos (2016-2017) 25

Flix Garca Carballeira Sistemas Distribuidos (2016-2017) 26

Entrega de mensajes acotada

Tiempo de ejecucin de procesos acotado

Entrega de mensajes no acotada

Tiempo de ejecucin de procesos totalmente arbitraria

Sistemas parcialmente sncronos

Flix Garca Carballeira Sistemas Distribuidos (2016-2017) 27

Paso de mensajes sncrono