Algoritmos distribuidos - Arcos

Transcripción

Diseño de Sistemas Distribuidos
Máster en Ciencia y Tecnología Informática
Curso 2014-2015
Modelos y algoritmos distribuidos
Félix García Carballeira
Grupo de Arquitectura de Computadores
[email protected]
Principales características de un sistema
distribuido
!  Múltiples procesos
!  Comunicación entre procesos
!  Espacio de direcciones disjuntos
!  Ausencia de reloj global
!  Procesos deben interactuar y cooperar para alcanzar un
objetivo común
• Félix García Carballeira
• Sistemas Distribuidos (2014-2015)
• 2
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
!  …
• 3
Motivación: ZooKeeper
!  Servicio de coordinación 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:
Implementar consenso
Elección de líder
Barreras de sincronización
Cerrojos distribuidos
Servicios de gestión de grupos de procesos
" 
" 
" 
" 
" 
• 4
Funcionamiento
• 5
Modelo de datos
Znode
Almacenado en memoria
Espacio de nombres
jerárquicos
!  Tipos:
Normales
Efímeros
Secuenciales
! 
" 
" 
" 
" 
" 
• 6
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)
• 7
Servidores
client
client
server
replica
server
replica
client
client
client
server
replica
• 8
Servidores
client
client
• read
server
replica
server
replica
client
client
client
server
replica
• 9
Servidores
client
client
• write
server
• propagate & sych
client
client
replica
server
replica
client
server
replica
• 10
Fallos
client
client
server
replica
server
replica
client
client
client
server
replica
• 11
¿Qué ofrece ZooKeeper?
!  Consistencia secuencial: las actualizaciones de un cliente se
aplican en el orden en el que fueron enviadas
!  Atomicidad: las actualizaciones se realizan de forma atómica
!  Imagen única del sistema con independencia del servidor al
que se conecta
!  Fiabilidad: cuando una actualización se completa, perdura
• 12
¿Cómo lo consigue?
!  Broadcast atómico
Entrega de mensajes fiable, si un mensaje se entrega a un
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 después de que un mensaje A
ha sido entregado por el emisor de B, A debe ser ordenado
antes que B
Si un proceso envía C después de enviar B, C debe
ordenarse después de B
" 
" 
" 
• 13
¿Cómo lo consigue?
!  El orden total lo consigue con identificadores únicos en los
mensajes (proceso líder)
!  Elección de líder
!  La consistencia se asegura utilizando Quorums
• 14
¿En qué se basa ZooKeeper?
!  En algoritmos distribuidos utilizados para:
" 
" 
" 
" 
" 
Ordenar de eventos
Entrega causal de mensajes
Elección de un proceso coordinador (líder)
Consenso distribuido
…
• 15
Problemas típicos en sistemas
distribuidos
!  Sincronización de relojes
!  Exclusión mutua
!  Consenso distribuido
!  Comunicación en grupos
!  Gestión de réplicas
!  Estados globales
• 16
Modelos de sistemas distribuidos
!  Modelo síncrono
Relojes sincronizados
Entrega de mensajes acotada
Tiempo de ejecución de procesos acotado
!  Modelo asíncrono
No hay sincronización de relojes
Entrega de mensajes no acotada
Tiempo de ejecución de procesos totalmente arbitraria
!  Sistemas parcialmente síncronos
Tiempos acotados pero desconocidos
" 
" 
" 
" 
" 
" 
" 
• 17
Tipos de pasos de mensajes
!  Paso de mensajes síncrono
" 
El envío y la recepción de un mensaje m, ocurren
simultáneamente
!  Paso de mensajes asíncrono
" 
El envío de un mensaje m y su recepción no están acoplados. No
tienen porque ocurrir de forma consecutiva
• 18
Modelo de sistema distribuido
!  Modelo de sistema:
Procesos secuenciales {P1, P2, ...Pn} que ejecutan un
algoritmo local
Canales de comunicación
!  Eventos en Pi
Ei = {ei1, ei2, ...ein}
!  Tipos de eventos locales
Internos (cambios en el estado de un proceso)
Comunicación (envío, recepción)
e
e
e
e
P0
!  Diagramas espacio-tiempo
" 
" 
" 
" 
" 
01
02
03
04
e05
P1
e11
e12
e13
• 19
Sistema distribuido como un sistema de
transición de estados
!  Un sistema distribuido se puede modelar como un sistema
de transición 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
" 
" 
La configuración actual de cada proceso/procesador
Los mensajes en tránsito por la red
• 20
Configuraciones y estados
!  En el sistema de transición de estados del sistema distribuido
" 
" 
Los estados se denominan configuraciones
Las transiciones se denominan transiciones de configuración
!  En el sistema de transición de estados de cada proceso
" 
" 
Los estados se denominan estados
Las transiciones se denominan eventos
!  Una ejecución en un sistema distribuido es una secuencia de
configuraciones (γ1, γ2, γ3, …) donde:
γ1 es una configuración inicial,
Hay una transición entre γi→γi+1 para todo i ≥ 1
La secuencia puede ser finita o infinita
!  Una ejecución o secuencia de estados define el comportamiento del
sistema
" 
" 
" 
• 21
Historia de un sistema distribuido
• 22
Algoritmos locales
!  Algoritmo local:
" 
" 
" 
Un proceso cambia de un estado a otro (evento inerno)
Un proceso cambia de un estado a otro y envía un mensaje a otro
proceso (evento de envío)
Un proceso recibe un mensaje y cambia su estado (evento de
recepción)
!  Restricciones
" 
" 
Un proceso p solo puede recibir un mensaje después de
haber sido enviado por otro
Un proceso p solo puede cambiar del estado c al estado d si
está actualmente en el estado c
• 23
Orden causal
!  La relación ≤H sobre eventos de una ejecución distribuida, denominada
orden causal, se define como:
" 
" 
" 
Si e ocurre antes que f en el mismo proceso, entonces e ≤H f
Si s es un evento de envío y r su correspondiente evento de recepción,
entonces s ≤H r
≤H Es transitiva
! 
" 
Si a ≤H b y b ≤H c entonces a ≤H c
≤H es reflexiva.
! 
a ≤H a para cualquier evento
!  Dos eventos , a y b, son concurrentes sii a ≤H b y b ≤H a
• 24
Ejemplos de eventos
• Eventos concurrentes
• Eventos relacionados
causalmente
• p1
• p2
• p3
• time
• Eventos relacionados
causalmente
• 25
Ejecuciones equivalentes
!  Dos ejecuciones distribuidas F y E son equivalentes (F~E )
si:
" 
" 
Tienen el mismo conjunto de eventos
Se mantiene el orden causal
• 26
Ejemplos de ejecuciones equivalentes
• p1
• Mismo color ~ orden causal
• p2
• p3
• tiempo
• p1
• p2
• p3
• tiempo
• p1
• p2
• p3
• tiempo
• 27
Algoritmos distribuidos
!  Los algoritmos distribuidos deben tener las siguientes
propiedades:
La información relevante se distribuye entre varias
máquinas
Los procesos toman las decisiones sólo en base a la
información local
Debe evitarse un punto único de fallo
No existe un reloj común
" 
" 
" 
" 
• 28
Ejemplos de algoritmos distribuidos
!  ordenación de eventos
!  Exclusión mutua distribuida
!  Algoritmos de elección
!  Comunicación multicast y ordenación de mensajes
!  Problemas de consenso
!  Detección de interbloqueos
!  Asignación de recursos
!  Planificación
!  Tolerancia a fallos
• 29
Ordenación de eventos
!  Monitorización del comportamiento de una aplicación distribuida
" 
Ejemplo: El observador debe ordenar los eventos de recepción de
mensajes en los procesos P1 y P2
!  e1, e2, e3, e4, e5
P1
m1
m3
m2
m4
m5
P2
Observador
e1
e2
e3
e4
e5
• 30
Ejemplo
!  Monitorización del comportamiento de una aplicación distribuida
" 
El observador debe ordenar los eventos de recepción de mensajes en los
procesos P1 y P2
!  e1, e2, e3, e4, e5
P1
m1
m3
m2
m4
m5
P2
Observador
e1
e2
e3
e4
e5
!  Para ordenar eventos podemos asignarles marcas de tiempo
!  ei ← ek
⇔ MT(ei) < MT (ek )
• 31
¿Marcas de tiempo en el observador?
P1
m1
m2
P2
Observador
e2
e1
?
• 32
¿Marcas de tiempo en de los procesos?
P1
P2
Observador
3
1
m1
6
m2
e1-6
8
e2-3
?
• 33
¿Marcas de tiempo en de los procesos?
P1
P2
Observador
3
1
m1
6
m2
e1-6
8
e2-3
Los relojes deben estar sincronizados
• 34
Relojes físicos
!  Para ordenar dos eventos de un proceso basta con asignarles
una marca de tiempo
!  Para un instante físico t
Hi(t): valor del reloj HW (oscilador)
Ci(t): valor del reloj SW (generado por el SO)
" 
" 
!  Ci(t) = a Hi(t) + b
" 
Ej: # ms o ns transcurridos desde una fecha de referencia
!  Resolución del reloj: periodo entre actualizaciones de Ci(t)
" 
Determina la ordenación de eventos
!  Dos relojes en dos computadores diferentes dan medidas
distintas
Necesidad de sincronizar relojes físicos de un sistema
distribuido
" 
• 35
Sincronización de relojes físicos
!  D: Cota máxima de sincronización
!  S: fuente del tiempo UTC, t
!  Sincronización externa:
Los relojes están sincronizados si |S(t) - Ci(t)| < D
Los relojes se consideran sincronizados dentro de D
!  Sincronización interna entre los relojes de los computadores de
un sistema distribuido
Los relojes están sincronizados si |Ci(t) - Cj(t)| < D
Dados dos eventos de dos computadores se puede establecer
su orden en función de sus relojes si están sincronizados
!  Sincronización externa ⇒ sincronización interna
" 
" 
" 
" 
⇐
• 36
Relojes lógicos
!  Dado que no se pueden sincronizar perfectamente los relojes
físicos en un sistema distribuido, no se pueden utilizar relojes
físicos para ordenar eventos
!  ¿Podemos ordenar los eventos de otra forma?
P1
m1
m3
m2
m4
m5
P2
Observador
e1
e2
e3
e4
e5
• 37
Causalidad potencial
!  En ausencia de un reloj global la relación causa-efecto
(precede a) es la única posibilidad de ordenar eventos
!  Relación de causalidad potencial (Lamport)
eij = evento j en el proceso i
Si j < k entonces eij ← eik
Si ei=send(m) y ej=receive(m), entonces ei ← ej
La relación es transitiva
!  Dos eventos son concurrentes (a || b) si no se puede deducir
entre ellos una relación de causalidad potencial
" 
" 
" 
" 
• 38
Importancia de la causalidad potencial
!  Sincronización de relojes lógicos
!  Depuración distribuida
!  Registro de estados globales
!  Monitorización
!  Entrega causal
!  Actualización de réplicas
• 39
Relojes lógicos (algoritmo de Lamport)
!  Algoritmo de Lamport (1978)
!  Cada proceso P mantiene una variable entera RLp (reloj lógico)
!  Cuando un proceso P genera un evento, RLp=RLp+1
!  Cuando un proceso envía un mensaje m a otro le añade 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)
• 40
Ejemplo
• p1
• 0
• 1
• 2
• 3
• 4
• p2
• 0
• 4
• 5
• p3
• 0
• 1
• 6
• tiempo
• 41
Relojes lógicos totalmente ordenados
!  Los relojes lógicos de Lamport imponen sólo una relación de
orden parcial:
" 
Eventos de distintos procesos pueden tener asociado una
misma marca de tiempo.
!  Se puede extender la relación de orden para conseguir una
relación de orden total añadiendo el nº de proceso
(Ta, Pa): marca de tiempo del evento a del proceso P
" 
!  (Ta, Pa) < (Tb, Pb) sí y solo si
" 
" 
Ta < Tb o
Ta=Tb y Pa<Pb
• 42
Problemas de los relojes lógicos
!  No bastan para caracterizar la causalidad
" 
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 relación (F(e), <) tal que:
" 
" 
a ≤H b si y sólo si F(a) < F(b)
Los relojes vectoriales permiten representar de forma
precisa la relación de causalidad potencial
• 43
Problemas de los relojes lógicos
P1
P2
P3
e11
e12
(1)
(2)
e21
e22
(1)
(3)
e31
e32
e33
(1)
(2)
(3)
C(e11) < C(e22), y e11←e22 es cierto
C(e11) < C(e32), pero e11 ← e32 es falso
• 44
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
Inicialmente RVi= 0 ∀ i
Cuando un proceso i genera un evento
!  RVi[i ] = RVi[i ] +1
Todos los mensajes llevan el RV del envío
Cuando un proceso j recibe un mensaje con RV
!  RVj = max(RVj , RV ) (componente a componente)
!  RVj[j ] = RVj[j ] +1 (evento de recepción)
" 
" 
" 
" 
• 45
Ejemplo
• [1,0,0]
• p1
• [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
• 46
Propiedades de los relojes vectoriales
!  RV < RV´ si y solo si
RV ≠ RV´ y
RV[i ] ≤ RV´[i ], ∀ i
!  Dados dos eventos a y b
a ≤H b si y solo si RV(a) < RV(b)
a y b son concurrentes cuando
" 
" 
" 
" 
!  Ni RV(a) ≤ RV(b)[i ]
ni RV(b ) ≤ RV(b)
• 47
Utilidad
• p1
• [1,0,0]
• [2,0,0]
• [3,0,0]
• [4,0,0]
• [5,0,0]
• p2
• [5,2,0]
• [0,1,0]
• [5,3,0]
• p3
• [0,0,1]
• [5,0,2]
• [5,0,3]
• time
• p2 analiza dos mensajes que recibe: de p1 [4,0,0] y de p2 [5,0,3] y puede
deducir que el de p1 es anterior [4,0,0] ≤ [5,0,3]
• 48
Entrega causal
!  Se distinguen los eventos recibir y entregar
!  Entrega FIFO
sendi(m) ≤H sendi(m´) entonces entregak(m) ≤H entregak(m´)
!  Entrega causal
sendi(m) ≤H sendj(m´) entonces entregak(m) ≤H entregak(m´)
!  La entrega causal requiere retrasar la entrega de un mensaje a un
proceso hasta estar seguros que entre dos envíos no hay uno
intermedio
!  Se puede implementar con relojes vectoriales
" 
" 
• 49
Ejemplo de entrega no causal
P1
m
P2
m’
P3
send(m) ≤H send(m’) pero en P3 se recibe antes m’
• 50
Utilidad
• p1
• [1,0,0]
• [2,0,0]
• [3,0,0]
• [4,0,0]
• [5,0,0]
• p2
• [5,2,0]
• [0,1,0]
• [5,3,0]
• p3
• [0,0,1]
• [5,0,2]
• [5,0,3]
• time
• p2 analiza dos mensajes que recibe: de p1 [4,0,0] y de p2 [5,0,3] y puede
deducir que el de p1 es anterior [4,0,0] ≤ [5,0,3]
• 51
Exclusión mutua distribuida
!  Los procesos ejecutan el siguiente fragmento de código
entrada()
SECCIÓN CRÍTICA
salida()
!  Requisitos para resolver el problema de la sección crítica
Exclusión mutua
Progreso
Espera acotada
!  Algoritmos
Algoritmo centralizado
Algoritmo distribuido
Anillo con testigo
…..
" 
" 
" 
" 
" 
" 
" 
• 52
Algoritmo centralizado
0
2
1
0
1
2
OK
C
1
salida
entrada
entrada
0
No hay respuespuesta
(bloquea al cliente)
C
2
OK
C
• 53
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 sección crítica (SC) envía
un mensaje a todos los procesos (y a él mismo) con una marca
de tiempo lógica
}  Cuando un proceso recibe un mensaje
Si el receptor no está en la SC ni quiere entrar envía 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 envía OK. En
caso contrario entra y no envía nada.
}  Cuando un proceso recibe todos los mensajes puede entrar
} 
} 
} 
• 54
Ejemplo
a)  Dos procesos (P0, P2) quieren entrar en la región al mismo
tiempo
b)  El proceso 0 tiene la marca de tiempo más baja, entra él.
c)  Cuando el proceso 0 acaba, envía un OK, de esa forma el
proceso 2 entra
• 55
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 envía el testigo al nuevo proceso del
anillo
• 56
Ejemplo. Algoritmo de votación de
Maekawa
!  Idea: no solicitar permiso de todos los procesos, solo de un
subconjunto
Los subconjuntos deben solaparse
!  A cada proceso Pi se le asocia un conjunto de votantes
{ Vi | i = 1, …, N }
!  Pi está en Vi
!  Vi ∩ Vj ≠ ∅
!  Todos subconjuntos de igual tamaño
!  Cada proceso Pj está contenido en M subconjutos
votantes
!  Solución optima
K~ N
M=K
" 
" 
" 
" 
• 57
Algoritmo de votación 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;
}
• 58
Algoritmo de votación de Maekawa
release():
state :=RELEASED;
Multicast release to processes in Vi - { Pi };
When Pj receives a release msg from Pi i
if(request queue == EMPTY) {
voted := FALSE;
} else {
Remove head of queue, P(k);
Reply to process P(k);
voted := TRUE;
}
≠ j:
• 59
Cerrojos en ZooKeeper
• 60
Algoritmos de elección
!  Útil en aplicaciones donde es necesario la existencia de un
coordinador
Varios procesos necesitan elegir un líder/coordinador
Por ejemplo, en una red token ring, cuando el testigo se pierde
En ZooKeeper cuando el coordinador falla
!  El algoritmo debe ejecutarse cuando falla el coordinador
!  Algoritmos de elección
Algoritmo del matón
Algoritmo de anillo
!  El objetivo de los algoritmos es que la elección sea única aunque el
algoritmo se inicie de forma concurrente en varios procesos
" 
" 
" 
" 
" 
• 61
Variantes del problema
!  ¿Comunicación síncrona o asíncrona?
!  ¿Cómo están conectados los procesos?
En anillo, completamente conectados, …
!  ¿El número de procesos es conocido?
!  ¿Los procesos tienen un identificador único?
" 
• 62
Algoritmo del máton
!  Suposiciones:
" 
" 
" 
Comunicación síncrona
Procesos completamente conectados
Entrega de mensajes fiable
• 63
Algoritmo del matón. Ejemplo
}  Utiliza timeouts (T) para detectar fallos
}  Asume que cada proceso conoce qué procesos tiene ID
mayores
}  3 tipos de mensajes:
#  coordinador: anuncio a todos los procesos con IDs menores
#  elección: enviado a procesos con IDs mayores
#  OK: respuesta a elección
}  Si no se recibe dentro de T, el emisor de elección envía
coordinador
}  En caso contrario, el proceso espera durante T a recibir un
mensaje coordinador. Si no llega comienza una nueva
elección
• 64
!  Cuando un proceso P observa que el coordinador no responde
inicia una elección:
a) Proceso 4 envía elección
b) Proceso 5 y 6 responden, diciéndole que pare
c) Ahora 5 y 6 comienzan la elección …
• 65
d) 
e) 
Proceso 6 dice a 5 que pare
Proceso 6 indica a todos que es el coordinador
• 66
Algoritmo LCR (basado en anillo)
!  Algoritmo LeLarnn, Chang y Roberts
!  Suposiciones:
" 
" 
" 
" 
Comunicación síncrona
Procesos en anillo
Identificador único para cada proceso
Tamaño de la red desconocida
• 67
Algoritmo del anillo
!  Cualquier proceso puede comenzar la elección y envía un
mensaje de elección a su vecino con su identificador y se
marca como participante
!  Cuando un proceso recibe un mensaje de elección compara el
identificador del mensaje con el suyo:
" 
" 
" 
" 
Si es mayor reenvía el mensaje al siguiente
Si es menor y no es un participante sustituye el identificador del
mensaje por el suyo y lo reenvía.
Si es menor y es un participante no lo reenvía
Cuando se reenvía un mensaje el proceso se marca como participante
!  Cuando un proceso recibe un identificador con su número y es
el mayor se elige como coordinador
!  El coordinador notifica al resto
• 68
Algoritmo del anillo
!  El 2 y el 5 generan mensajes de elección y lo envían al siguiente
!  Se elige como coordinador el proceso que recibe un mensaje con su nº y es
el mayor
!  Este proceso a continuación envía mensajes a todos informando que es el
coordinador
1
2
2
6
0
3
3
6
4
7
6
5
5
• 69
Comunicación multicast
!  Las primitivas de comunicación básicas soportan la
comunicación uno a uno.
!  Broadcast: el emisor envía un mensaje a todos los nodos del
sistema.
!  Multicast: el emisor envía un mensaje a un subconjunto de
todos los nodos.
!  Estas operaciones se emplean normalmente mediante
operaciones punto a punto.
• 70
Utilidad
!  Servidores replicados: un servicio replicado consta de un grupo
de servidores. Las peticiones de los clientes se envían a todos los
miembros del grupo. Aunque algún miembro del grupo falle la
operación se realizará.
!  Mejor rendimiento:
Replicando datos.
Cuando se cambia un dato, el nuevo valor se envía a todos los
procesos que gestionan las réplicas.
" 
" 
• 71
Tipos de multicast
!  Multicast no fiable: no hay garantía de que el mensaje se
entregue a todos los nodos.
!  Multicast fiable: el mensaje es recibido por todos los nodos en
funcionamiento.
!  Multicast atómico: el protocolo asegura que todos los
miembros del grupo recibirán los mensajes de diferentes nodos
en el mismo orden.
!  Multicast causal: asegura que los mensaje se entregan de
acuerdo con las relaciones de causalidad.
• 72
Justificación del multicast atómico
!  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
dos bases de datos.
Al mismo tiempo se paga un 10% de intereses, enviando un
multicast a las dos bases de datos.
¿Qué ocurre si los mensajes llegan en diferente a orden a las
dos bases de datos?
" 
" 
" 
• 73
Implementación del multicast
!  Implementación de operaciones multicast:
" 
" 
Mediante operaciones punto a punto.
Mecanismo poco fiable.
!  Problemas de fiabilidad:
" 
" 
Alguno de los mensajes se puede perder.
El proceso emisor puede fallar después de realizados
algunos envíos. En este caso algunos procesos no recibirán
el mensaje.
• 74
Multicast fiable
!  Se envía un mensaje a todos los procesos y se espera confirmación
de todos.
Si todos confirman el multicast se ha completado.
Si alguno no confirma se retransmite. Si no envía confirmación se
puede asumir que el proceso ha fallado y se elimina del grupo.
!  Si el emisor falla durante el proceso la operación no será atómica.
Para que la operación sea atómica, si el emisor falla alguno de los
receptores debe completar el envío a todos los demás.
" 
" 
" 
!  Cuando un proceso recibe un mensaje lo envía al resto
!  Cuando un proceso recibe un mensaje envía una confirmación y
monitoriza al emisor para ver si falla. Si falla completa el multicast.
!  En cualquier caso hay que descartar los mensajes duplicados
• 75
Ejemplo de multicast sin ordenación
P1
P2
P3
P4
A
B
A
B
Tiempo
• 76
Ordenación de las actualizaciones
!  Es importante el orden en el que se realizan las peticiones
¿Qué ocurre en un sistema asíncrono cuando un cliente
modifica un dato y más tarde otro cliente quiere consultar
ese dato?
!  Algunas aplicaciones requieren un orden en la realización 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.
!  Ordenación causal: se basa en la relación 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
• 77
Ordenación total y causal
t2
t1
tiempo
c1
c2
c3
FE1
GR1
GR2
GR3
FE2
• 78
Problemas en servidores georeplicados
• 79
Tipos de anomalías que no siguen orden
causal (1)
• 80
causal (2)
• 81
causal (3)
• 82
Implementación
!  Una petición recibida no se entrega hasta que las restricciones de
ordenación se puedan cumplir.
!  Un mensaje estable pasa a la cola de entrega
!  Debe asegurarse
Seguridad: ningún mensaje fuera de orden
Progreso: todos los mensajes se entregan
" 
" 
entrega
cola de
espera
cola de
entrega
Peticiones
• 83
Implementación de la ordenación total
}  Se asigna a cada petición un identificador de orden total
(IOT)
}  Este identificador se utiliza para entregar los mensajes en el
mismo orden a todos los procesos
}  Método centralizado:
"  Se utiliza un proceso secuenciador encargado de asignar
IOT a los mensajes
"  Cada mensaje se envían al secuenciador
}  El secuenciador incrementa IOT
}  El secuenciador le asigna un IOT y lo envía a los procesos
Cuando un proceso recibe un mensaje con un IOT mayor
del esperado, pide al secuenciador que le envíe de nuevo el
mensaje
"  Posible cuello de botella y punto de fallo crítico
" 
• 84
Método distribuido
! 
! 
Birman y Joseph 1987
Cada proceso q en el grupo almacena:
Aq: mayor número de secuencia acordado que se ha observado hasta el
momento
Pq: su mayor número de secuencia propuesto
Los identificadores deben incluir el número de proceso para asegurar un orden
total
Cuando un proceso p realiza un BCAST envía el mensaje al resto
Cada proceso q que recibe el mensaje de p
Propone Pq=Max(Aq, Pq) + 1
Almacena (m, Pq) en su cola y lo marca como no entregable
Envía Pq al emisor del mensaje (p)
El proceso q recibe todos los números de secuencia propuesto y selecciona el mayor
A como el siguiente número de secuencia acordado y lo envía a todos
En q se fija Aq = Max(Aq, A) y se marca el mensaje como entregable
Se reordena la cola y si está el primero se entrega
" 
" 
" 
! 
! 
" 
" 
" 
! 
" 
" 
• 85
Ejemplo
• Nodo 1
• A1 = 14
• Multicast (M1)
M3
M1
M2
15.1
16.1
17.1
U
U
U
…
• Nodo 2
• A12 = 15
• Multicast(M2)
M2
M1
M3
16.2
17.2
18.2
U
U
U
• Nodo 3
• A3 = 16
• Multicast(M3)
…
M1
M3
M2
17.3
18.3
19.3
U
U
U
…
• Etapa 1:
•  Los mensajes llegan a los receptores en orden distinto
•  Se les propone un número de secuencia
•  Se insertan en la cola y se marcan como no entregables
• 86
Ejemplo
• Nodo 1
• A1 = 14
M3
M1
M2
15.1
17.3
17.1
U
U
U
…
• Nodo 2
• A12 = 15
• Multicast(M2)
M2
M1
M3
16.2
17.3
18.2
U
U
U
• Nodo 3
• A3 = 16
• Multicast(M3)
…
M1
M3
M2
17.3
18.3
19.3
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 máximo y se las envía al resto
• 87
Ejemplo
• Nodo 1
• A1 = 14
M3
M2
M1
15.1
17.1
17.3
U
U
D
…
• Nodo 2
• A12 = 15
• Multicast(M2)
M2
M1
M3
16.2
17.3
18.2
U
D
U
• Nodo 3
• A3 = 16
• Multicast(M3)
…
M1
M3
M2
17.3
18.3
19.3
D
U
U
…
• Etapa 2:
•  Se marca M1 como entregable y se reordenan las colas
•  M1 no se puede entregar en ningún nodo
• 88
Ejemplo
• Nodo 1
• A1 = 14
M3
M2
M1
15.1
17.1
17.3
U
U
D
…
• Nodo 2
• A12 = 15
• Multicast(M2)
M2
M1
M3
16.2
17.3
18.2
U
D
U
• Nodo 3
• A3 = 16
• Multicast(M3)
…
M1
M3
M2
17.3
18.3
19.3
D
U
U
…
• Etapa 3:
• 89
Ejemplo
• Nodo 1
• A1 = 14
M3
M2
M1
15.1
19.3
17.3
U
U
D
…
• Nodo 2
• A12 = 15
• Multicast(M2)
M2
M1
M3
19.3
17.3
18.2
U
D
U
• Nodo 3
• A3 = 16
• Multicast(M3)
…
M1
M3
M2
17.3
18.3
19.3
D
U
U
…
• Etapa 3:
•  y calcula el máximo y se las envía al resto
• 90
Ejemplo
• Nodo 1
• A1 = 14
M3
M1
M2
15.1
17.3
19.3
U
D
D
…
• Nodo 2
• A12 = 15
• Multicast(M2)
M1
M3
M2
17.3
18.2
19.3
D
U
D
• Nodo 3
• A3 = 16
• Multicast(M3)
…
M1
M3
M2
17.3
18.3
19.3
D
U
D
…
• Etapa 3:
•  M2 se marca como entregable y se reordenan las colas
• 91
Ejemplo
• Nodo 1
• A1 = 14
M3
M1
M2
15.1
17.3
19.2
U
D
D
…
• Nodo 2
• A12 = 15
• Multicast(M2)
M3
M2
18.2
19.3
U
D
…
• Nodo 3
• A3 = 16
• Multicast(M3)
M3
M2
18.3
19.3
U
D
…
• Etapa 3:
•  M2 se marca como entregable y se reordenan las colas
•  M1 se entrega en el nodo 2 y 3
• 92
Ejemplo
• Nodo 1
• A1 = 14
M3
M1
M2
15.1
17.3
19.2
U
D
D
…
• Nodo 2
• A12 = 15
• Multicast(M2)
M3
M2
18.2
19.3
U
D
…
• Nodo 3
• A3 = 16
• Multicast(M3)
M3
M2
18.3
19.3
U
D
…
• Etapa 4:
•  y calcula el máximo (18.3) y se las envía al resto
• 93
Ejemplo
• Nodo 1
• A1 = 14
M3
M1
M2
18.3
17.3
19.2
U
D
D
…
• Nodo 2
• A12 = 15
• Multicast(M2)
M3
M2
18.3
19.3
U
D
…
• Nodo 3
• A3 = 16
• Multicast(M3)
M3
M2
18.3
19.3
U
D
…
• Etapa 4:
•  y calcula el máximo (19.3) y se las envía al resto
• 94
Ejemplo
• Nodo 1
• A1 = 14
M1
M3
M2
17.3
18.3
19.2
D
D
D
…
• Nodo 2
• A12 = 15
• Multicast(M2)
M3
M2
18.3
19.3
D
D
…
• Nodo 3
• A3 = 16
• Multicast(M3)
M3
M2
18.3
19.3
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
• 95
Implementación de la ordenación 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
"  Todos los procesos inicializan el vector a 0
"  Cuando pi envía un nuevo mensaje incrementa VTi(i) en 1 y
añade VT al mensaje
}  Cuando a pj le llega un mensaje de pi con VT se entrega si:
"  vt(i) = VTj(i) + 1 (siguiente en la secuencia de pi)
"  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
• 96
Ejemplo
P0
(0,0,0)
P1
(0,0,0)
P2
(0,0,0)
(0,1,0) (0,1,1)
(0,1,0)
(0,1,1)
(0,1,0)
(0,1,1)
• 97
Ejemplo
!  Vector enviado por el proceso 0: (4, 6, 8, 2, 1, 5)
!  Vector en el proceso 1: (3, 7, 8, 2, 1, 5)
!  Vector en el proceso 2: (3, 5, 8, 2, 1, 5)
!  ¿Se puede entregar el mensaje enviado por el 0?
" 
Al 1 si:
!  Es el siguiente en la secuencia de mensajes recibidos del 0 y
no se han perdido mensajes.
" 
Al 2 no:
!  Es el siguiente en la secuencia de mensajes recibidos del 0.
!  Le falta un mensaje del proceso 1
• 98
Problemas de consenso
!  Objetivo: que un conjunto de procesos se pongan de acuerdo en una
determinada acción o valor.
!  Un servicio de consenso consta de
Un conjunto de N procesos que deben tener una visión
consensuada de un determinado objeto, valor o acción
Clientes que envían peticiones a los procesos para proponer un
valor
Objetivo: que el conjunto de procesos consensuen un valor
!  Un protocolo de consenso es correcto sii:
Todos los nodos deciden el mismo valor (seguridad)
El valor decidido debe haber sido propuesto por algún nodo
Todos los nodos deciden el valor en el algún momento
(terminación)
" 
" 
" 
" 
" 
" 
• 99
Aplicaciones
!  Transacciones distribuidas
!  En grupos de procesos
!  Servidores replicados
• 100
Two-phase-commit
!  Two-phase-commit (2PC), Jim Gray (1970)
!  Denominamos coordinador al proceso que realiza la operación
Coordinador:
P0
P1
multicast: ok to commit?
OK to commit
recoger las respuestas
todos ok => send(commit)
else => send(abort)
Procesos:
ok to commit=> guardar
la petición en un
área temporal y responder ok
commit => hacer los cambios
permanentes
abort => borrar los datos temporales
P2
Grabar en
área temporal
ok
¡Commit!
Hacer los cambios
permanentes
• 101
Ejemplo
• ok to commit?
• 102
Ejemplo
• ok to commit?
• ok
• 103
Ejemplo
• ok to commit?
• ok
• commit
• Hacer los
cambios
permanentes
• 104
Modos de fallo en sistemas distribuidos
!  Fallo parada (fail stop): el nodo que falla no se recupera
!  Fallo por omisión: fallo que causa que un componente no
responda en algunas ocasiones
!  Fallo con recuperación (fail recover): un componente falla,
pero continua su ejecución sin fallo posteriormente
!  Fallos de tiempo: el componente responde demasiado tarde, no
se cumple el rendimiento esperado, ..
!  Fallos bizantinos: funcionamiento arbitrario
• 105
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 información del protocolo en
almacenamiento persistente
" 
!  Cuando el proceso se recupera recupera la información
previamente guardada
" 
Se utilizan timeouts para evitar los bloqueos en el protocolo
• 106
Ejemplo con fallo en la respuesta
• Coordinador
A
B
C
• ok to commit?
• ok
• Proceso falla
• 107
Ejemplo con fallo en la respuesta
• Coordinador
A
B
C
• ok to commit?
• ok
• Proceso falla
• timeout
• 108
Ejemplo con fallo respuesta
• Coordinador
A
B
C
• ok to commit?
• ok
• Proceso falla
• abort
• 109
Fallo en el coordinador
• Coordinador
A
B
C
• ok to commit?
• ok
• commit
• 110
Fallo en el coordinador
!  El proceso C puede enviar un mensaje al coordinador
pidiéndole la decisión
Si la recibe OK
Si no la recibe tiene que esperar a que el coordinador se
recupere
!  El proceso C puede solicitar la decisión a alguno de los otros
participantes
" 
" 
• 111
Acciones después de una recuperación
!  Si falló el coordinador, cuando reinicia:
Si el estado fue “commit” entonces envía “commit”
Si en estado fue “abort” entonces envía “abort”
!  Si falló un proceso, cuando reinicia:
Si no encontró “ok” aborta la operación
Si encontró “ok”, ejecuta el protocolo de terminación para
decidir
" 
" 
" 
" 
• 112
Fallos de bloqueo del protocolo 2PC
!  El coordinador envía una petición “ok to commit” a A, B, C y D
!  Todos responden “ok”
!  El coordinador envía “commit” a A y a continuación el
coordinador y A fallan
!  B, C y D han respondido “ok” pero no reciben “commit” ni del
coordinador ni de A
• 113
Imposibilidad de consenso
!  En un sistema síncrono es posible
!  En un sistema asíncrono es imposible
" 
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é?
" 
En un sistema asíncrono: no se puede determinar si un
proceso ha fallado o no (puede ejecutar más lento o sus
mensajes pueden retrasarse)
!  No existe un detector de fallos
!  En sistemas síncronos 3PC asegura seguridad y terminación
!  2PC no asegura terminación
• 114
Three-phase commit
•  coordinador
participantes (A, B, C …)
• canCommit?
• yes
• prepareCommit
• ACK
Fase 1
Fase 2
• doCommit
• haveCommitted
Fase 3
•  Dale Skeen el al. (1980)
• 115
¿Resuelve el problema de bloqueo?
!  Asumir que el coordinador y A fallan en la fase 3 justo
después del doCoomit a A
!  Si alguno de los procesos restantes ha recibido prepareCommit
puede terminar el protocolo
!  Si ninguno ha recibido prepareCommit, abortan
• 116
Empleo de timeouts
•  coordinador
participantes (A, B, C …)
• canCommit?
• yes
• prepareCommit
Timeout -> abortar
• ACK
• doCommit
Timeout -> abortar
• haveCommitted
Fase 1
Timeout -> abortar
Fase 2
Timeout -> commit
Fase 3
• 117
Particiones de red
!  2PC y 3PC no funcionan en caso de particiones de red
!  A recibe prepareCommit del coordinador
!  Ocurre una partición 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
• 118
Consenso basado en quorums
!  Se definen dos operaciones READ y WRITE
!  Hay un conjunto de N nodos, que sirven peticiones
" 
" 
" 
" 
Un READ debe realizarse sobre R copias
Un WRITE debe realizarse sobre W copias
Cada réplica tiene un número de versión V
Debe cumplirse que:
!  R + W > N
!  W + W > N
!  R, W < N
• 119
Método de votación
!  READ
Se lee de R réplicas, se queda con la copia con la última
versión
!  WRITE
Hay que asegurarse que todas las réplicas se comportan
como una sola (seriabilidad)
Se realiza en primer lugar una operación READ para
determinar el número de versión actual.
Se calcula el nuevo número de versión.
Se inicia un 2PC para actualizar el valor y el número de
versión en W o más réplicas.
" 
" 
" 
" 
" 
• 120
Votación jerárquica
!  El problema de los esquemas basados en quorum es que W
aumenta al aumentar el número de réplicas
!  Solución: quorum jerárquico
Ej: número de réplicas = 5 x 5 = 25 (nodos hoja)
" 
• 0
• 1
• 2
• 121
Votación jerárquica
!  El quorum se realiza por niveles
R1W1
1 5
1 5
1 5
2 4
2 4
3 3
R2
1
2
3
2
3
3
W2
5
4
3
4
3
3
RT
1
2
3
4
6
9
WT
25
20
15
16
12
9
¿Cuál se elige?
• 122
Replicación de datos utilizando 2PC
!  Sea un conjunto de procesos {P0, P1,...,Pn} que mantienen una réplica 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 número de réplicas que deben leerse para una
operación READ
Se denota como qu el número de réplicas que deben actualizarse para un
UPDATE.
Para utilizar esquemas basados en quorum se necesita:
qr + qu > n
qu+qu > n
" 
" 
• 123
!  Para tolerar t fallos, será necesario que
qu no sea mayor que n-t
r>t
!  Se asocia un número de versión a cada dato. El número de versión se
incrementa en cada actualización.
!  READ: el proceso lee qr réplicas y descarta las réplicas con números
pequeños. El resto deben ser idénticos y se utilizará como valor leído.
!  UPDATE: utiliza el protocolo 2PC
Se realiza en primer lugar una operación READ para determinar el
número de versión actual.
Se calcula el nuevo número de versión.
Se inicia un 2PC para escribir el valor y el nº de versión en qu o más
réplicas.
" 
" 
" 
" 
" 
• 124
!  UPDATE (Continuación)
" 
" 
" 
" 
" 
Una réplica indica abortar si ella tiene un nº de versión
mayor
En caso contrario bloquea las READ y espera en ok to
commit
El coordinador comprometerá el resultado si sólo recibe
mensajes commit de al menos qu réplicas. En caso contrario
aborta.
Las operaciones READ se retrasan durante el estado ok to
commit.
Si llegan operaciones UPDATE en ok to commit las aborta
• 125
Paxos
!  Leslie Lamport (1989)
!  Protocolo para alcanzar consenso basado en máquinas de
estado finito (asegura seguridad y terminación)
!  Todos los nodos alcanan consenso a pesar de fallos en los
nodos, particiones de red y retrasos en la entrega de mensajes
• 126
Aplicación de Paxos
!  Google: Chubby (servicio de cerrojos distribuido basado en
Paxos)
Bigtable y otros servicios de Google utilizan Chubby
!  Yahho: ZooKeeper (servicio de cerrojos distribuido basado en
Paxos)
" 
• 127
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
!  Terminación no garantizada en casos muy improbables en el
mundo real
• 128
Idea básica
!  Similar a 2PC pero con dos procesos (proposer, aceptors)
!  Uno o más nodos deciden ser coordinador (proposer)
!  El nodo proposer propone un valor y solicita la aceptación de
un conjunto de nodos aceptors
!  El nodo proposer anuncia el valor elegido o lo intenta de
nuevo sino se ha alcanzado un valor
• 129
Idea básica
• 130
Idea básica
!  Cualquier nodo puede
proponer/(aceptar
• 131
Mecanismos utilizados en Paxos
!  Las propuestas van ordenadas con un número 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
fallos
Resuelve los problemas de partición (no puede haber dos
mayorías simultáneamente)
" 
" 
• 132
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 mayoría,
elige ese valor
!  El nodo proposer envía el valor elegido a todos los nodos
!  Todas las propuestas llevan un orden global
• 133
Ordenación de las propuestas
!  Cada aceptor debe ser capaz de aceptar múltiples propuestas
!  Cada propuesta lleva asociada un número de orden global que
utilizan los nodos acceptors para aceptar/rechazar
Ej: (dirección de nodo:número de secuencia local)
!  Reglas para aceptar propuestas:
Cuando un nodo acceptor recibe una nueva propuesta con
número N, lo compara con el número de propuesta M ya
aceptada
" 
" 
!  Si N > M acepta la nueva propuesta, en caso contrario la
rechaza
" 
Si el acceptor decide aceptar la nueva propuesta N, le pide
al proposer que utilice el mismo valor de la propuesta M
• 134
Protocolo detallado
!  Cada nodo almacena:
" 
" 
" 
(Na. Va): propuesta con número más alta y su valor
Nh: número de propuesta más alto visto
N: número de propuesta actual
• 135
Fase 1
!  Fase 1 (Propuesta):
" 
" 
" 
" 
Un nodo decide hacer una propuesta (líder)
Elige N > Nh
Envía (propuesta, N) a todos los nodos
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
• 136
Fase 2
! 
Fase 2 (Aeptar):
IF el lider obtiene una mayoría de OK
!  V = valor del Na recibido más alto
!  IF (V = null) el lider elige cualquier valor V
!  Envía (aceptar, N, -V) a todos los nodos
IF el lider no obtiene mayoría
!  Espera y reinicia el protocolo
Cuando un nodo recibe (aceptar, N, V)
IF (N < Nh)
Responde con rechazar
ELSE
Na = N; Va = V; Nh=N
Responder OK
" 
" 
" 
• 137
Fase 3
!  Fase 3 (decidir)
" 
Si el lider recibe OK de una mayoría
!  Envía (decidir, Va) a todos los nodos
" 
Sino espera (aleatoriamente) y reinicia el protocolo
• 138
Ejemplo
• 139
Acuerdo bizantino
!  En la mayoría de las ocasiones cuando un componente o
sistema falla, su funcionamiento es arbitrario.
Pueden enviar información diferente a diferentes
componentes con los que se comunica.
Alcanzar un acuerdo entre las observaciones que hacen
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.
Permite construir procesadores con fallos de tipo falloparada
" 
" 
" 
" 
• 140
Definición del problema
!  Sistema distribuido compuesto por una serie de nodos
(generales) que intercambian información entre ellos.
!  Los componentes pueden exhibir fallos bizantinos (generales
traidores)
Un nodo con fallo puede enviar información diferente a
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.
• 141
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.
emisor
1
0
nodo i
1
nodo i
1
nodo j
emisor
0
0
nodo j
• 142
Solución 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 observación Oi
Cada nodo mantiene un vector V con información 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 envía un mensaje al resto indicando su observación.
Cuando un nodo recibe una observación actualiza su vector y
envía a los otros dos nodos la observación recibida.
} 
} 
} 
} 
} 
} 
} 
} 
} 
• 143
Solución
!  Después del intercambio de mensajes, cada nodo construye un
vector con los valores mayoritarios
!  Si no existe mayoría entonces se asume que no hay un
observación coherente.
• 144
Ejemplo. Etapa inicial
Nodo 1
*
*
*
*
Nodo 4
*
*
Nodo 2
*
E
*
A
*
*
Nodo 3
*
*
A
*
• 145
Ejemplo. Primer intercambio de mensajes
Nodo 1
*
*
*
*
Nodo 4
E
A
Nodo 2
A
E
R
A
A
E
Nodo 3
R
A
A
E
V3(1) V3(2) V3(3) V3(4)
• 146
Ejemplo. Segundo intercambio de mensajes
Nodo 1
*
Nodo 4
E
R
*
*
Nodo 2
V4(j)
V2(j)
E
V1(j)
V1(j)
A
V2(j)
A
A
R
R
*
E
A
V3(j)
Nodo 3
R
A
E
Vi(1) Vi(2) Vi(3) Vi(4)
R
E
A
E
V3(j)
R
V1(j)
E
V2(j)
A
R
V3(j)
R
V4(j)
E
A
A
E
R
R
E
A
Vi(1) Vi(2) Vi(3) Vi(4)
V3(j)
Vi(1) Vi(2) Vi(3) Vi(4)
Vi(j) -> La observación que de j dice i
• 147
Etapa final
Nodo 2
Nodo 1
V2(j)
*
*
*
*
Nodo 4
R
A
A
R
A
V1(j)
V3(j)
R
V4(j)
E
A
E
R
R
E
A
Vi(1) Vi(2) Vi(3) Vi(4)
E
Nodo 2
Nodo 3
R
A
R
A
A
A
E
E
• 148
El problema del interbloqueo
!  Situación en la que cada proceso
está bloqueado en espera de un
recurso (o evento) que está asignado
a (o sólo puede producir)
un proceso (también bloqueado) del
conjunto
!  Tipos:
De recursos
De comunicación
PA
R2
PB
R1
• Interbloqueo
" 
" 
• 149
Estrategias
!  Modelización de interbloqueos mediantes grafos
!  Prevención de interbloqueos
!  Evitación de interbloqueos
!  Detección de interbloqueos
• 150
Estados globales consistentes
!  En un sistema distribuido existen ciertas situaciones que no es
posible determinar de forma exacta por falta de un estado
global:
Recolección de basura: Cuando un objeto deja de ser
referenciado por ningún elemento del sistema.
Detección de interbloqueos: Condiciones de espera cíclica
en grafos de espera (wait-for graphs).
Detección de estados de terminación: El estado de actividad
o espera no es suficiente para determinar la finalización de
un proceso.
" 
" 
" 
• 151
Definiciones
El estado global de un sistema distribuido se denota por G=(S,L),
donde:
S={s1, s2, s3, s4,...,sM} : Estado interno de cada uno de los M
procesadores.
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
Sj
m2
m2
mk
Si
Cij
Lij={m , …, m }
1
k
• 152
Snapshots
El análisis de los estados globales de un sistema se realiza por
medio de snapshots: Agregación del estado local de cada
componente así como de los mensajes actualmente en
transmisión.
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 evaluación de dicho estado.
• 153
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 también 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
!  Si para un mensaje m, el evento receive(m) ∈ C, entonces el
evento send(m) ∈ C.
" 
• 154
Ejemplos
• 155
Cortes Consistentes
Corte no consistente
p1
p2
p3
Corte consistente
p1
p2
p3
m1
m2
m4 no se
ha enviado
m3
m4
m4 ya ha
llegado
m5
m2
m3
m4
m5
• 156
m1
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 envía 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
estado de un canal depende del proceso emisor
" 
• 157
Algoritmo
!  Proceso iniciador (p) de forma atómica:
Registra su estado local Sp
Registra el estado del canal entrante desde q a p como vacío
P envía el marcador a todos sus vecinos a través de los canales saliente.
!  Cuando un proceso recibe un marcador:
La primera vez hace lo del iniciador
Cuando p recibe un marcador desde otro proceso r:
!  P registra el estado del canal de r a p como la secuencia de mensajes
que p ha recibido de r desde que p registró su estado Sp
!  El algoritmo termina para un proceso una vez que ha recibido el marcador
de cada canal entrante
" 
" 
" 
" 
" 
• 158
Algoritmo
!  Una vez registrados todos los estados (el algoritmo ha
terminado)
El estado global consistente puede ensamblarse en cada
proceso haciendo que cada proceso envíe los datos del
estado que él ha registrado
" 
• 159

Algoritmos distribuidos - Arcos

Transcripción

Documentos relacionados

Presentación de PowerPoint - Pagina oficial de la asociacion

Pincha AQUÍ