Diseño de Sistemas Distribuidos - ARCOS – …±o de Sistemas Distribuidos Máster en Ciencia y...

Diseño de Sistemas DistribuidosMáster en Ciencia y Tecnología Informática

Curso 2017-2018

Félix García CarballeiraGrupo de Arquitectura de [email protected]

Modelos y algoritmos distribuidos

•Félix García Carballeira •Sistemas Distribuidos (2017-2018) •1

Principales características de un sistema distribuido§ Múltiples procesos§ Comunicación y sincronización 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 común


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§ …


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:q Implementar consenso distribuidoq Elección de líderq Barreras de sincronizaciónq Cerrojos distribuidosq Configuración dinámicaq Servicios de gestión de grupos de procesos


ZooKeeper en Hadoop


¿Por qué es difícil la coordinación en sistemas distribuidos?§ El emisor no puede saber:

q Si el mensaje fue recibidoq Si el receptor falló antes o después de procesar el mensaje


Impossibility of distributed consensus with one faulty processMichael 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 jerárquica en memoria§ Los clientes establcecen una sesión cuando se conectan a

ZooKeerper


Modelo de datos


§ Znodeq Almacenado en memoriaq Espacio de nombres

jerárquicosq No están pensados para

almacenamiento general (varios KB)

§ Tipos:q Normalesq Efímerosq Secuenciales

§ Los clientes pueden manipular los znodes a través del API de ZooKeeper

Tipos de znodes

§ Efímeros: los znodes creados por un cliente son borrados al final de la sesión del cliente (o fallo del cliente)

§ Secuenciales: incrementan un contador añadido 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 informacióndel nodo ha cambiado

§ Las notificaciones indican el cambio no los nuevos datos


Sesiones

§ Un cliente se conecta a ZooKeeper e inicia una sesión§ Las sesiones tienen asociado un timeout§ ZooKeeper considera que un cliente falla si no recibe nada una

vez expirado el timeout§ La sesión finaliza cuando el cliente falla o cuando la cierra de

forma explícita


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

client

client

client

server

server

server

replica

replica

replica

Servidores


client

client

client

client

client

server

server

server

replica

replica

replica

•read

Servidores


client

client

client

client

client

server

server

server

replica

replica

replica

•write

•propagate & sych

•broadcast atómico

Fallos


client

client

client

client

client

server

server

server

replica

replica

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 atómica§ Imagen única del sistema con independencia del servidor al

que se conecta§ Fiabilidad: cuando una actualización se completa, perdura


¿Cómo lo consigue?

§ Broadcast atómicoq 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: q 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

q Si un proceso envía C después de enviar B, C debe ordenarse después de B


¿Cómo lo consigue?

§ El orden total lo consigue con identificadores únicos en los mensajes (proceso líder)

§ Algoritmo de elección de líder§ La consistencia se asegura utilizando Quorums


¿En qué se basa ZooKeeper?

§ En algoritmos distribuidos utilizados para:q Ordenar de eventosq Entrega causal de mensajesq Elección de un proceso coordinador (líder)q Consenso distribuidoq …


Problemas típicos en sistemas distribuidos§ Sincronización de relojes§ Exclusión mutua§ Elección de líder§ Consenso distribuido§ Comunicación en grupos§ Gestión de réplicas§ Estados globales


Algoritmos distribuidos

§ Algoritmos que trabajan en sistemas distribuidos§ Realizan tareas:

q Comunicaciónq Gestión de datos y de recursosq Sincronizaciónq Consenso

§ Deben trabajar bajo:q Actividades concurrentes en múltiples localizacionesq Incertidumbre del tiempo, ordenación de eventos, .q Posibilidad de fallos (procesos, procesadores, redes)


Teorema CAP


Modelos de sistemas distribuidos

§ Modelo síncronoq Relojes sincronizadosq Entrega de mensajes acotadaq Tiempo de ejecución de procesos acotado

§ Modelo asíncronoq No hay sincronización de relojesq Entrega de mensajes no acotadaq Tiempo de ejecución de procesos totalmente arbitraria

§ Sistemas parcialmente síncronosq Tiempos acotados pero desconocidos

•Félix García Carballeira •27•Sistemas Distribuidos (2017-2018)

Tipos de pasos de mensajes

§ Paso de mensajes síncronoq El envío y la recepción de un mensaje m, ocurren

simultáneamente

§ Paso de mensajes asíncronoq El envío de un mensaje m y su recepción no están acoplados. No

tienen porque ocurrir de forma consecutiva


Modelo de sistema distribuido

§ Modelo de sistema:q Procesos secuenciales {P1, P2, ...Pn} que ejecutan un

algoritmo localq Canales de comunicación

§ Eventos en Pi

q Ei = {ei1, ei2, ...ein}§ Tipos de eventos locales

q Internos (cambios en el estado de un proceso)q Comunicación (envío, recepción)

§ Diagramas espacio-tiempo P0e01 e02 e03 e05e04

e11 e12 e13P1


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 estados2. → describe las posibles transiciones(→ Í C ´ C)3. I describe los estados iniciales(I Í C)

§ El estado de un sistema distribuido, C, se puede describir comoq La configuración actual de cada proceso/procesadorq Los mensajes en tránsito por la red


Configuraciones y estados

§ En el sistema de transición de estados del sistema distribuidoq Los estados se denominan configuracionesq Las transiciones se denominan transiciones de configuración

§ En el sistema de transición de estados de cada procesoq Los estados se denominan estadosq Las transiciones se denominan eventos

§ Una ejecución en un sistema distribuido es una secuencia deconfiguraciones (g1, g2, g3, …) donde:q g1 es una configuración inicial, q Hay una transición entre gi→gi+1 para todo i ≥ 1q La secuencia puede ser finita o infinita

§ Una ejecución o secuencia de estados define el comportamiento del sistema


Historia de un sistema distribuido


Algoritmos locales

§ Algoritmo local:q Un proceso cambia de un estado a otro (evento inerno)q Un proceso cambia de un estado a otro y envía un mensaje a otro

proceso (evento de envío)q Un proceso recibe un mensaje y cambia su estado (evento de

recepción)§ Restricciones

q Un proceso p solo puede recibir un mensaje después de haber sido enviado por otro

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


Orden causal

§ La relación ≤H sobre eventos de una ejecución 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 envío y r su correspondiente evento de recepción, 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

•p1

•p2

•p3•time

•Eventos relacionados causalmente

•Eventos concurrentes •Eventos relacionados causalmente


Ejecuciones equivalentes

§ Dos ejecuciones distribuidas F y E son equivalentes (F~E ) si: q Tienen el mismo conjunto de eventosq Se mantiene el orden causal


Ejemplos de ejecuciones equivalentes

•p1

•p2

•p3•tiempo

•p1

•p2

•p3•tiempo

•p1

•p2

•p3•tiempo

•Mismo color ~ orden causal


Algoritmos distribuidos

§ Los algoritmos distribuidos deben tener las siguientes propiedades:q La información relevante se distribuye entre varias

máquinasq Los procesos toman las decisiones sólo en base a la

información localq Debe evitarse un punto único de falloq No existe un reloj común


Ejemplos de algoritmos distribuidos

§ Sincronización de relojes§ 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


Ordenación de eventos


§ Monitorización del comportamiento de una aplicación distribuidaq Ejemplo: el observador debe ordenar los eventos de recepción de

mensajes en los procesos P1 y P2§ e1, e2, e3, e4, e5

P1

P2

Observador

m1 m2 m3 m4 m5

e1 e2 e3 e4 e5


Ejemplo

§ Monitorización del comportamiento de una aplicación distribuidaq El observador debe ordenar los eventos de recepción de mensajes en los

procesos P1 y P2§ e1, e2, e3, e4, e5

P1

P2

Observador

m1 m2 m3 m4 m5

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

P2

Observador

m1 m2

e1e2

?


¿Marcas de tiempo en de los procesos?

P1

P2

Observador

m1 m2

e1-6

1

6

3

8

e2-3

?


¿Marcas de tiempo en de los procesos?

P1

P2

Observador

m1 m2

e1-6

1

6

3

8

e2-3

Los relojes deben estar sincronizados


Relojes físicos

§ Para ordenar dos eventos de un proceso basta con asignarles una marca de tiempo

§ Para un instante físico tq Hi(t): valor del reloj HW (oscilador)q Ci(t): valor del reloj SW (generado por el SO)

§ Ci(t) = a Hi(t) + bq Ej: # ms o ns transcurridos desde una fecha de referencia

§ Resolución del reloj: periodo entre actualizaciones de Ci(t)q Determina la ordenación de eventos

§ Dos relojes en dos computadores diferentes dan medidas distintasq Un reloj actual puede tener una deriva de1s al díaq Necesidad de sincronizar relojes físicos de un sistema

distribuido


Sincronización de relojes físicos

§ D: Cota máxima de sincronización§ S: fuente del tiempo UTC, t § Sincronización externa:

q Los relojes están sincronizados si |S(t) - Ci(t)| < D q Los relojes se consideran sincronizados dentro de D

§ Sincronización interna entre los relojes de los computadores de un sistema distribuidoq Los relojes están sincronizados si |Ci(t) - Cj(t)| < Dq 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Þ

Ü


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

P2

Observador

m1 m2 m3 m4 m5

e1 e2 e3 e4 e5


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)q eij = evento j en el proceso iq Si j < k entonces eij ¬ eik

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

q La relación es transitiva§ Dos eventos son concurrentes (a || b) si no se puede deducir

entre ellos una relación de causalidad potencial


Aplicación de los relojes lógicos

§ Sincronización de relojes lógicos§ Depuración distribuida§ Registro de estados globales§ Monitorización§ Entrega causal§ Actualización de réplicas

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)


Ejemplo

•p1

•p2

•p3

•tiempo

•1 •3

•4

•1

•4

•5

•6

•2•0

•0

•0



Relojes lógicos totalmente ordenados

§ Los relojes lógicos de Lamport imponen sólo una relación de orden parcial:q 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 procesoq (Ta, Pa): marca de tiempo del evento a del proceso P

§ (Ta, Pa) < (Tb, Pb) sí y solo siq Ta < Tb oq Ta=Tb y Pa<Pb

Algoritmo de Welch

§ ¿Qué ocurre si el sistema ya dispone de un reloj?q No se puede cambiar el valor del reloj si es mantenido por

un algoritmo diferente§ Algoritmo de Welch

q En lugar de avanzar el reloj en respuesta a los mensajes que llegan, se retrasa la entrega de esos mensajes hasta que se alcanza el valor de tiempo

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


Problemas de los relojes lógicos

§ No bastan para caracterizar la causalidadq 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:q a ≤H b si y sólo si F(a) < F(b)q Los relojes vectoriales permiten representar de forma

precisa la relación de causalidad potencial



Problemas de los relojes lógicos

C(e11) < C(e22), y e11¬e22 es ciertoC(e11) < C(e32), pero e11 ¬ e32 es falso

P1e11

(1)

e12

(2)

P2e21

(1)

e22

(3)

P3e31

(1)

e32

(2)

e33

(3)

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 " iq Cuando un proceso i genera un evento

§ RVi[i ] = RVi[i ] +1q Todos los mensajes llevan el RV del envíoq 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)


Ejemplo

•p1

•p2

•p3

•tiempo

•[2,0,0] •[4,0,0]

•[4,2,0]

•[0,0,2]

•[5,0,0]

•[4,3,0]

•[4,3,3]

•[3,0,0]•[1,0,0]

•[0,1,0]

•[0,0,1]


Propiedades de los relojes vectoriales

§ RV < RV´ si y solo siq RV RV´ yq RV[i ] £ RV´[i ], " i

§ Dados dos eventos a y bq a ≤H b si y solo si RV(a) < RV(b)q a y b son concurrentes cuando

§ Ni RV(a) £ RV(b)[i ] ni RV(b ) £ RV(b)

¹


Entrega causal

§ Se distinguen los eventos recibir y entregar§ Entrega FIFO

q sendi(m) ≤H sendi(m´) entonces entregak(m) ≤H entregak(m´)§ Entrega causal

q 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


Ejemplo de entrega no causal

P1

P2

P3

m

m’

send(m) ≤H send(m’) pero en P3 se recibe antes m’



Exclusión mutua distribuida

§ Los procesos ejecutan el siguiente fragmento de códigoentrada()SECCIÓN CRÍTICAsalida()

§ Requisitos para resolver el problema de la sección críticaq Exclusión mutuaq Progresoq Espera acotada

§ Algoritmosq Algoritmo centralizadoq Algoritmo distribuidoq Anillo con testigoq …..

Algoritmo centralizado


0

entradaOK

C

1 2

No hay respuespuesta(bloquea al cliente)

0

entrada

C

1 2

OK

0

salida

C

1 2

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•Félix García Carballeira •Sistemas Distribuidos (2017-2018) •63

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

•64•Félix García Carballeira •Sistemas Distribuidos (2017-2018)

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



Ejemplo. Algoritmo de votación de Maekawa§ Idea: no solicitar permiso de todos los procesos, solo de un

subconjuntoq Los subconjuntos deben solaparse

§ A cada proceso Pi se le asocia un conjunto de votantesq { 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

q K ~ q M = K

N


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;

}


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 ≠ j:if(request queue == EMPTY) {

voted := FALSE;} else {

Remove head of queue, P(k);Reply to process P(k);voted := TRUE;

}

Cerrojos en ZooKeeper


Algoritmos de elección

•70

§ Útil en aplicaciones donde es necesario la existencia de un coordinadorq Varios procesos necesitan elegir un líder/coordinadorq Por ejemplo, en una red token ring, cuando el testigo se pierdeq En ZooKeeper cuando el coordinador falla

§ El algoritmo debe ejecutarse cuando falla el coordinador§ Algoritmos de elección

q Algoritmo del matónq 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

•Félix García Carballeira •Sistemas Distribuidos (2017-2018)

Variantes del problema

§ ¿Comunicación síncrona o asíncrona?§ ¿Cómo están conectados los procesos?

q En anillo, completamente conectados, …§ ¿El número de procesos es conocido?§ ¿Los procesos tienen un identificador único?


Elección de líder con ZooKeeper


Algoritmo del máton

§ Suposiciones:q Comunicación síncronaq Procesos completamente conectadosq Entrega de mensajes fiable


Algoritmo del matón. Ejemplo

•74

} 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 menoresn elección: enviado a procesos con IDs mayoresn 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



•75

§ Cuando un proceso P observa que el coordinador no responde inicia una elección:

a) Proceso 4 envía elecciónb) Proceso 5 y 6 responden, diciéndole que parec) Ahora 5 y 6 comienzan la elección …



•76

d) Proceso 6 dice a 5 que paree) Proceso 6 indica a todos que es el coordinador


Algoritmo LCR (basado en anillo)

§ Algoritmo LeLarnn, Chang y Roberts§ Suposiciones:

q Comunicación síncronaq Procesos en anilloq Identificador único para cada procesoq Tamaño de la red desconocida


Algoritmo del anillo

•78

§ 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:q Si es mayor reenvía el mensaje al siguienteq Si es menor y no es un participante sustituye el identificador del

mensaje por el suyo y lo reenvía.q Si es menor y es un participante no lo reenvíaq 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


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

0 3

7 4

56

3

5

26

6


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.


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: q Replicando datos.q Cuando se cambia un dato, el nuevo valor se envía a todos los

procesos que gestionan las réplicas.


§ 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.

Tipos de multicast


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.q Un usuario ingresa 200 eurosenviando un multicast a las

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

multicast a las dos bases de datos.q ¿Qué ocurre si los mensajes llegan en diferente a orden a las

dos bases de datos?


Implementación del multicast

§ Implementación 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 después de realizados

algunos envíos. En este caso algunos procesos no recibirán el mensaje.


Multicast fiable

§ Se envía un mensaje a todos los procesos y se espera confirmación de todos. q Si todos confirman el multicast se ha completado.q 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.

q 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


Ejemplo de multicast sin ordenación

A

A

B

B

P1 P2 P3 P4

Tiempo


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 r2entonces r1 se procesa antes que r2 en todos los procesos


Ordenación total y causal

t1

c1

c2 c3

tiempo

FE1 GR1 GR2 GR3 FE2

t2


Problemas en servidores georeplicados


Tipos de anomalías que no siguen orden causal (1)



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

q Seguridad: ningún mensaje fuera de ordenq Progreso: todos los mensajes se entregan

Peticiones

entrega

cola deespera

cola deentrega

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:q Se utiliza un proceso secuenciador encargado de asignar

IOT a los mensajesq Cada mensaje se envían al secuenciador

} El secuenciador incrementa IOT} El secuenciador le asigna un IOT y lo envía a los procesos

q Cuando un proceso recibe un mensaje con un IOT mayor del esperado, pide al secuenciador que le envíe de nuevo el mensaje

q Posible cuello de botella y punto de fallo crítico


Método distribuido§ Birman y Joseph 1987§ Cada proceso q en el grupo almacena:

q Aq: mayor número de secuencia acordado que se ha observado hasta el momento

q Pq: su mayor número de secuencia propuestoq 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

q Propone Pq=Max(Aq, Pq) + 1q Almacena (m, Pq) en su cola y lo marca como no entregableq 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 todosq En q se fija Aq = Max(Aq, A) y se marca el mensaje como entregableq Se reordena la cola y si está el primero se entrega


Ejemplo


•Nodo 1•A1 = 14•Multicast (M1)

•Nodo 3•A3 = 16•Multicast(M3)


…

•Inicialmente:• Los tres nodos realizan un multicast simultáneo

Ejemplo





…

•Inicialmente:• Los tres nodos realizan un multicast simultáneo

Ejemplo





M3 M1 M2

15.1 16.1 17.1 …

U U U

M2 M1 M3

16.2 17.2 18.2 …

U U U

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, Pq=Max(Aq, Pq) + 1• (se añade identificador de proceso)• Se insertan en las colas y se marcan como no entregables (U)

Ejemplo





M3 M1 M2

15.1 17.3 17.1 …

U U U

M2 M1 M3

16.2 17.3 18.2 …

U U U

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 de las tres, y se las envía al resto (17.3)

Ejemplo





M3 M2 M1

15.1 17.1 17.3 …

U U D

M2 M1 M3

16.2 17.3 18.2 …

U D U

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 se puede entregar en el nodo 3 porque ser el primero de la cola

Ejemplo





M3 M2 M1

15.1 17.1 17.3 …

U U D

M2 M1 M3

16.2 17.3 18.2 …

U D U

M3 M2

18.3 19.3 …

U U

•Etapa 2:• M1 se entrega en el nodo 3

Ejemplo





M3 M2 M1

15.1 17.1 17.3 …

U U D

M2 M1 M3

16.2 17.3 18.2 …

U D U

M3 M2

18.3 19.3 …

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 máximo (19.3)

Ejemplo





M3 M2 M1

15.1 19.3 17.3 …

U U D

M2 M1 M3

19.3 17.3 18.2 …

U D U

M3 M2

18.3 19.3 …

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 máximo (19.3)• Se la envía al resto

Ejemplo





M3 M1 M2

15.1 17.3 19.3 …

U D D

M1 M3 M2

17.3 18.2 19.3 …

D U D

M3 M2

18.3 19.3 …

U D

•Etapa 3:• M2 se marca como entregable y se reordenan las colas

Ejemplo





M3 M1 M2

15.1 17.3 19.2 …

U D D

M3 M2

18.2 19.3 …

U D

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

Ejemplo





M3 M1 M2

15.1 17.3 19.2 …

U D D

M3 M2

18.2 19.3 …

U D

M3 M2

18.3 19.3 …

U D

•Etapa 4:• El Nodo 3 recibe las marcas asociada a M3 envidas por el nodo 1 (15.1) y 3 (18.2) • Calcula el máximo de todas (18.3)

Ejemplo





M3 M1 M2

18.3 17.3 19.2 …

U D D

M3 M2

18.3 19.3 …

U D

M3 M2

18.3 19.3 …

U D

•Etapa 4:• El Nodo 3 recibe las marcas asociada a M3 envidas por el nodo 1 (15.1) y 3 (18.2) • Calcula el máximo de todas (18.3)• Se las envía al resto

Ejemplo





M1 M3 M2

17.3 18.3 19.2 …

D D D

M3 M2

18.3 19.3 …

D D

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 (se asegura el orden de entrega en todos los nodos)

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

q Todos los procesos inicializan el vector a 0q 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:

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


Ejemplo

•110

P0 (0,0,0)

(0,0,0) (0,1,0)

(0,1,0) (0,1,1)

(0,1,0) (0,1,1)

(0,1,1)

(0,0,0)

P1

P2


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?


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?

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


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 deq Un conjunto de N procesos que deben tener una visión

consensuada de un determinado objeto, valor o acciónq Clientes que envían peticiones a los procesos para proponer un

valorq Objetivo: que el conjunto de procesos consensuen un valor

§ Un protocolo de consenso es correcto sii:q Todos los nodos deciden el mismo valor (seguridad)q El valor decidido debe haber sido propuesto por algún nodoq Todos los nodos deciden el valor en el algún momento

(terminación)•Félix García Carballeira •113•Sistemas Distribuidos (2017-2018)

Protocolos de consenso

§ Dado un conjunto de proceso P1….Pn que se comunicanmediante paso de mensajes, el objetivo es alcanzar un acuerdosobre un determinado valor aun en presencia de fallos


Algoritmo deconsenso

P1

P2

P3v1

v2

v3

Aplicaciones

§ Transacciones distribuidas§ En grupos de procesos§ Elección de líder§ Sincronización de relojes§ Servidores replicados


Two-phase-commit

§ Two-phase-commit (2PC), Jim Gray (1970)§ Denominamos coordinador al proceso que realiza la operación

Coordinador:multicast: ok to commit?

recoger las respuestastodos 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


P0OK to commit

Grabar en área temporal

¡Commit!

ok

Hacer los cambiospermanentes

P1 P2

Ejemplo


•ok to commit?

Ejemplo


•ok to commit?

•ok

Ejemplo


•ok to commit?

•ok•commit

•Hacer los cambiospermanentes

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


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

q Cada proceso almacena la información del protocolo en almacenamiento persistente§ Cuando el proceso se recupera recupera la información

previamente guardadaq Se utilizan timeouts para evitar los bloqueos en el protocolo


Ejemplo con fallo en la respuesta


•ok tocommit?

•ok •Proceso falla

•Coordinador A B C

Ejemplo con fallo en la respuesta


•ok to commit?

•ok •Proceso falla•timeout


Ejemplo con fallo respuesta


•ok to commit?

•ok •Proceso falla

•abort


Fallo en el coordinador


•ok to commit?

•ok

•commit


Fallo en el coordinador

§ El proceso C puede enviar un mensaje al coordinador pidiéndole la decisiónq Si la recibe OKq 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


Acciones después de una recuperación

§ Si falló el coordinador, cuando reinicia:q Si el estado fue “commit” entonces envía “commit”q Si en estado fue “abort” entonces envía “abort”

§ Si falló un proceso, cuando reinicia:q Si no encontró “ok” aborta la operaciónq Si encontró “ok”, ejecuta el protocolo de terminación para

decidir


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


Imposibilidad de consenso

§ En un sistema síncrono es posible§ En un sistema asíncrono es imposible

q Impossibility of distributed consensus with one faulty processMichael 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 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•Félix García Carballeira •Sistemas Distribuidos (2017-2018) •129

Three-phase commit


•canCommit?

• coordinador participantes (A, B, C …)

•yes

•prepareCommit•ACK

•doCommit•haveCommitted

Fase 1

Fase 2

Fase 3

• Dale Skeen el al. (1980)

¿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 prepareCommitpuede terminar el protocolo

§ Si ninguno ha recibido prepareCommit, abortan


Empleo de timeouts


•canCommit?

• coordinador participantes (A, B, C …)

•yes

•prepareCommit•ACK

•doCommit•haveCommitted

Fase 1

Fase 2

Fase 3

Timeout -> abortar

Timeout -> abortar

Timeout -> abortar

Timeout -> commit

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 commitde 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 copiasq Un WRITE debe realizarse sobre W copiasq Cada réplica tiene un número de versión Vq Debe cumplirse que:

§ R + W > N§ W + W > N§ R, W < N


Método de votación

§ READq Se lee de R réplicas, se queda con la copia con la última

versión§ WRITE

q Hay que asegurarse que todas las réplicas se comportan como una sola (seriabilidad)

q Se realiza en primer lugar una operación READ para determinar el número de versión actual.

q Se calcula el nuevo número de versión.q Se inicia un 2PC para actualizar el valor y el número de

versión en W o más réplicas.


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árquicoq Ej: número de réplicas = 5 x 5 = 25 (nodos hoja)


•0

•1

•2

Votación jerárquica

§ El quorum se realiza por niveles

R1W1 R2 W2 RT WT1 5 1 5 1 251 5 2 4 2 201 5 3 3 3 152 4 2 4 4 162 4 3 3 6 123 3 3 3 9 9

¿Cuál se elige?•Félix García Carballeira •Sistemas Distribuidos (2017-2018) •137

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:q qr + qu > nq qu+qu > n



§ Para tolerar t fallos, será necesario que q qu no sea mayor que n-tq 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 2PCq Se realiza en primer lugar una operación READ para determinar el

número de versión actual.q Se calcula el nuevo número de versión.q Se inicia un 2PC para escribir el valor y el nº de versión en qu o más

réplicas.



§ UPDATE (Continuación)q Una réplica indica abortar si ella tiene un nº de versión

mayorq En caso contrario bloquea las READ y espera en ok to

commitq El coordinador comprometerá el resultado si sólo recibe

mensajes commit de al menos qu réplicas. En caso contrario aborta.

q Las operaciones READ se retrasan durante el estado ok tocommit.

q Si llegan operaciones UPDATE en ok to commit las aborta


Paxos

§ Leslie Lamport (1989)§ Protocolo para alcanzar consenso basado en máquinas de

estado finito (asegura seguridad y terminación)§ Todos los nodos alcanzan consenso a pesar de fallos en los

nodos, particiones de red y retrasos en la entrega de mensajes


Aplicación de Paxos

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

§ 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

§ Terminación no garantizada en casos muy improbables en el mundo real


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


Idea básica





Idea básica





§ Cualquier nodo puede proponer/(aceptar

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

consensoq Permite que el sistema siga funcionando en presencia de

fallosq Resuelve los problemas de partición (no puede haber dos

mayorías simultáneamente)


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


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/rechazarq Ej: (dirección de nodo:número de secuencia local)

§ Reglas para aceptar propuestas:q 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

rechazaq Si el acceptor decide aceptar la nueva propuesta N, le pide

al proposer que utilice el mismo valor de la propuesta M•Félix García Carballeira •Sistemas Distribuidos (2017-2018) •149

Protocolo detallado

§ Cada nodo almacena:q (Na. Va): propuesta con número más alta y su valorq Nh: número de propuesta más alto vistoq N: número de propuesta actual


Fase 1

§ Fase 1 (Propuesta):q Un nodo decide hacer una propuesta (líder)q Elige N > Nhq Envía (propuesta, N) a todos los nodosq Cuando se recibe (propuesta, N)

IF (N < Nh)Responder rechazar

ELSENh = NResponder (propuesta-OK, Na, Va)No aceptará ninguna propuesta futura con valor < N


Fase 2

§ Fase 2 (Aeptar):q 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

q IF el lider no obtiene mayoría§ Espera y reinicia el protocolo

q Cuando un nodo recibe (aceptar, N, V)IF (N < Nh)

Responde con rechazarELSE

Na = N; Va = V; Nh=NResponder OK


Fase 3

§ Fase 3 (decidir)q Si el lider recibe OK de una mayoría

§ Envía (decidir, Va) a todos los nodosq Sino espera (aleatoriamente) y reinicia el protocolo


Ejemplo



Acuerdo bizantino

§ En la mayoría de las ocasiones cuando un componente o sistema falla, su funcionamiento es arbitrario.q Pueden enviar información diferente a diferentes

componentes con los que se comunica.q 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 acuerdosobre un determinado valor en un sistema donde los componentes pueden fallar de forma arbitraria.

§ Importancia:q Permite enmascarar fallos arbitrarios.q Permite construir procesadores con fallos de tipo fallo-

parada


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)q 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.


Problema con tres nodos

nodo k

nodo i nodo j

1

0 X

¿puede el nodo i y nodo k llegar a un consenso en el valor?



nodo k

nodo i nodo j

1 1

0

1

0 X



nodo k

nodo i nodo j

1 0

0

01

X


§ Utilizando tres nodos, si uno falla el problema no puede resolverse.

§ Se necesitan 3m+1 nodos para hacer frente a m fallos bizantinos


nodo k

nodo i nodo j

1 1

0

nodo k

nodo i nodo j

1 0

0

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.


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.


Ejemplo. Etapa inicial

*

A

* * *

* * * E * * *

* * A *

Nodo 1

Nodo 2

Nodo 3

Nodo 4


Ejemplo. Primer intercambio de mensajes

*

A

* * *

E A A E R A E

R A A E

Nodo 1

Nodo 2

Nodo 3

Nodo 4

V3(1) V3(2) V3(3) V3(4)


Ejemplo. Segundo intercambio de mensajes

*

A

* * *

E A A E R A E

R A A E

Nodo 1

Nodo 2

Nodo 3

Nodo 4

R E

R A

R A

R R

R E

E AE R

R E

E A

V2(j)

V1(j)

V3(j)

V4(j)

Vi(1) Vi(2) Vi(3) Vi(4)

V4(j)

V1(j)

V2(j)

V3(j)

Vi(1) Vi(2) Vi(3) Vi(4)

Vi(1) Vi(2) Vi(3) Vi(4)Vi(j) -> La observación que de j dice i

V3(j)

V1(j)

V2(j)

V3(j)


Etapa final

*

A

* * *

R A A E

R A E

R A A E

Nodo 1

Nodo 2

Nodo 3

Nodo 4

AR A E

Nodo 2

R R

R E

E A

V2(j)

V1(j)

V3(j)

V4(j)

Vi(1) Vi(2) Vi(3) Vi(4)


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:q De recursosq De comunicación


•Interbloqueo

PA

R1 PB

R2

Estrategias

§ Modelización de interbloqueos mediantes grafos§ Prevención de interbloqueos§ Evitación de interbloqueos§ Detección 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 Recolección de basura: Cuando un objeto deja de ser

referenciado por ningún elemento del sistema.q Detección de interbloqueos: Condiciones de espera cíclica

en grafos de espera (wait-for graphs).q Detección de estados de terminación: El estado de actividad

o espera no es suficiente para determinar la finalización 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 Mprocesadores.

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


Sj Si

m1 m2 mkm2

Lij={m1, …, mk}

Cij

•170

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.


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:q (a Î C) Ù (b ® a) Þ b Î C

§ Si para un mensaje m, el evento receive(m) Î C, entonces el evento send(m) Î C.


Cortes Consistentes

p1 p2 p3

m1m2

m3

m4

m5

m4 ya hallegado

m4 no seha enviado

p1 p2 p3

m1m2

m3

m4

m5

Corte no consistente Corte consistente


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.q Los canales son pasivos: la responsabilidad de registrar el

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

ejecución del algoritmo§ Cualquier proceso puede iniciar el algoritmo en cualquier

instante§ Los procesos pueden seguir enviando y recibiendo los

mensajes de aplicación durante la ejecución del algoritmo

§ Idea: es que cada proceso registre su estado y para cada canal, todos los mensajes que entraron después de que él registrata suestado y antes de que el emisor le envíe 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 atómica:q Registra su estado local S1q P1 envía el marcador a todos sus vecinos a través de los canales salientes.q A partir de este momento almacenará en los canales Ck1 los mensajes de

aplicación 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 vacío. Para el resto de canales se almacenarán los mensajes de aplicación a partir de ese momento

§ Reenvía un mensaje marcador al resto de procesos (entre la recepción del marcador y su reenvío no ejecuta ningún 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 envíe los datos del estado que él ha registrado, por ejemplo, a otro proceso


Ejemplo


saldo inicial

elementos disponibles

saldo inicial

elementos disponibles

Tipos de mensajes:• (order 10, $100): se piden 10 elementos y se transfiere $100• (5 widgets): se envían 5 elementos

Ejemplo


¿Qué estado se registra para cada proceso y cada canal?

Ejercicio¿qué estado se registra?


Diseño de Sistemas Distribuidos - ARCOS – …±o de Sistemas Distribuidos Máster en Ciencia y...

Documents

Transcript of Diseño de Sistemas Distribuidos - ARCOS – …±o de Sistemas Distribuidos Máster en Ciencia y...