Sincronización en Sistemas Distribuidos

Sistemas de Operación II
Sincronización en Sistemas Distribuidos
Prof. Carlos Figueira
Basado en material de
Yudith Cardinale (USB)
Andrew Tanembaum y Marteen van Steen
Contenido
●
Introducción
●
Relojes (temporizadores o timers)
●
Sincronización de relojes lógicos
●
Sincronización de relojes físicos
●
Exclusión mutua distribuida
●
Algoritmos de elección de coordinador
Carlos Figueira/USB
2
Algoritmos distribuidos:Propiedades
●
●
●
●
La información relevante se distribuye entre
varias máquinas.
Los procesos toman las decisiones sólo en
base a la información disponible en forma local.
Debe evitarse un punto de fallo único en el
sistema.
No existe un reloj común o alguna otra fuente
precisa del tiempo global.
Carlos Figueira/USB
3
Aspectos a considerar
●
Tiempos y estados globales.
●
Exclusión mutua.
●
●
Algoritmos de elección. Problemas de
consenso
Operaciones atómicas distribuidas:
Transacciones
Carlos Figueira/USB
4
Relojes y Sincronización
●
●
Reloj: circuito con contador (C),
registro de valor inicial (HR) y
cristal cuarzo que cuenta
oscilaciones
C
HR
Cuando C llega a 0, genera una
interrupción (tick), manejada por
software y escalada a unidad de
tiempo conveniente
Carlos Figueira/USB
5
Relojes
●
●
●
¿Pueden dos eventos tener el mismo registro
de reloj? Depende de resolución del reloj y la
frecuencia de ocurrencia de eventos
La frecuencia de un cristal de cuarzo es muy
estable, pero puede variar por: temperatura,
tamaño, forma de corte. ¡Puede desfasarse!
Desfase: diferencia entre reloj y una referencia
(reloj ideal) por unidad de tiempo medida
Carlos Figueira/USB
6
Sincronización de relojes físicos
●
●
●
Los relojes (hardware) de cada máquina de un
sistema distribuido no están sincronizados
(frecuencia, fase)
Sincronización es importante para:
●
Aplicaciones en tiempo real
●
Ordenación de eventos distribuidos
Concepto de sincronización:
●
Mantener relojes sincronizados entre sí
●
Mantenerlos sincronizados con la realidad
Carlos Figueira/USB
7
Relojes lógicos
●
●
●
En los sistemas/aplicaciones distribuidos
importa generalmente la secuencia de
ocurrencia de los eventos, no el tiempo exacto
Reloj Lógico: contador de software que se
incrementa de manera monotónica, cuyo valor
no necesita estar relacionado con ningún reloj
físico.
El reloj lógico nos permite ordenar eventos.
Generalmente se asocia a cada proceso un
reloj lógico
Carlos Figueira/USB
8
Sincronización de relojes lógicos:
Algoritmo de Lamport
●
Principios:
●
●
Si dos eventos ocurrieron en el mismo proceso,
entonces ocurrieron en el orden en que fueron
observados. Notación: x p y, donde x e y son
eventos que ocurren en el proceso P y “x ocurrió
antes que y”
Siempre que un mensaje es enviado entre
procesos, el evento de enviar el mensaje ocurre
antes de recibirlo
Carlos Figueira/USB
9
Algoritmo de Lamport (cont.)
●
Se generalizan estos ordenamientos con la
relación “pasó antes” (happened before), se
denota con → y se define como:
●
PA1: si existe un proceso P, tal que x
P
y
entonces x → y
●
PA2: para cualquier mensaje m, send(m) →recv(m)
●
PA3: (transitividad) si x,y,z son eventos tales que
x →y , y →z, entonces x →z
Carlos Figueira/USB
10
Algoritmo de Lamport (cont.)
P0
a
b
c
P1
P2
●
●
e
d
a
b
b
c
c
d
d
f
a
f
e
Si cada proceso tiene un reloj lógico Cp se puede asignar
un valor de tiempo a cada evento : Cp(a)
Propiedades:
●
Si a → b, entonces Cp(a) < Cp(b)
●
El valor de Cp siempre incrementa, nunca decrementa
Carlos Figueira/USB
11
Algoritmo de Lamport (cont.)
●
Ordenamiento Causal
●
●
●
●
LC1: Cp es incrementado antes que cada evento
sea ejecutado (Cp=Cp+1)
LC2: cuando un proceso P envía un mensaje m,
coloca en el mensaje el valor t=Cp
LC3: cuando un proceso Q recibe mensaje (m,t), Q
calcula Cq=max(Cq, t) y aplica LC1
¿Cp(a) < Cq(b) implica a →b ?
Carlos Figueira/USB
12
Algoritmo de Lamport: Ejemplo
P1
P2
P3
0
0
0
aA
6
10
b 8
12
16
20
c B
18
24
30
d
24
32
40
30
40
50
C e 60
36
48
f
42
56
70
g
48 h D
64
80
54
72
90
60
80
100
P1
P2
P3
0
0
0
a A
6
10
b 8
12
16
20
c B
18
24
30
d
24
32
40
30
40
50
C e 60
36
48
f
42
61
70
g
48 h D
69
80
70
77
90
76
85
100
Tres relojes no sincronizados
Sincronización de relojes
Carlos Figueira/USB
13
Sincronización de Relojes Físicos
●
●
●
Sincronizar los relojes físicos con la hora real
(referencia única)
Sincronizar los relojes físicos entre sí
Se toma en cuenta el Tiempo Universal
Coordinado (UTC)
Carlos Figueira/USB
14
Sincronización de Relojes Físicos
●
●
●
Tiempo Atómico Internacional (TAI) mantenido
por el BIH (Bureau International de l'Heure),
París
Laboratorios mantienen tiempo contando
transiciones del átomo de cesio-133. Un
segundo atómico es 9.192.631.770
transiciones del cesio-133
Cada lab. envía al BIH el número de ticks de su
reloj (se empezó en 1958). El BIH calcula el TAI
promediando las lecturas de los lab.
Carlos Figueira/USB
15
Sincronización de Relojes Físicos
●
●
●
●
Segundo solar: 1/86.400 veces el día solar
UTC es un estándar basado en TAI, usa unos
“segundos de salto” para sincronizar TAI con
segundos solares
En EEUU, el Instituto Nacional de Estándares y
Tecnología (NIST) difunde señal por onda corta
Otras posibilidades: NTP (Internet), Satélite
(GEPS. GPS)
Carlos Figueira/USB
16
TAI vs segundos solares
Carlos Figueira/USB
17
Sincronización relojes físicos: Alg.
de Cristian
●
Servidor de reloj en red
●
El tiempo nunca retrocede: ajustar gradualmente
●
¿Tiempo de tránsito? Estimarlo Tprop=((T2-T1)+(T4-T3))/2 =>
TA'=TB + Tprop, Θ = TA-TA'
Carlos Figueira/USB
18
Sincronización de Relojes Físicos
●
¿Cada cuánto se debe sincronizar?
●
●
●
Cada máquina tiene reloj que causa H
interrupciones por segundo. En la práctica, se
obtiene un error e
En cada interrupción se suma 1 al reloj del sistema
(C) que mantiene número de ticks desde una fecha
de referencia pasada
IDEAL: Si UTC=t, en máquina M se debe cumplir
que CM(t)=t para todo M,t. Así, se cumple dC/dt=1
Carlos Figueira/USB
19
Relación entre tiempo local y UTC
Carlos Figueira/USB
20
Sincronización de relojes físicos
●
Se cumple que: 1-e <= dC/dt <= 1+e
●
e es provisto por el fabricante
●
●
●
La idea es sincronizar el reloj con UTC y que entre
ellos no haya una diferencia mayor de δ.
En el peor caso, en un tiempo T un reloj se atrasa
eT y el otro se adelanta eT, siendo la diferencia en
tiempo entre ambos de 2eT.
Para que esta diferencia sea menor que δ (i.e.
2eT<δ), los relojes deben ser re-sincronizados
cada δ/2e segundos
Carlos Figueira/USB
21
Sincronización relojes físicos:
Algoritmo de Berkeley
●
●
Se basa en servidor de
tiempo activo (demonio
del tiempo), que
consulta el tiempo
periódicamente a cada
máquina (en Intranets)
Tiempo colocado
manualmente por
operador
Carlos Figueira/USB
22
Algoritmo de Berkeley
Carlos Figueira/USB
23
Sincronización relojes físicos:
Algoritmo de Berkeley
●
●
●
¿Qué ventaja tiene transmitir el ajuste y no la
hora?
¿Qué pasa si hay relojes con desfases muy
grandes?
El demonio toma promedio tolerante a fallas:
subconjunto de relojes seleccionados para
promediar son aquellos que no difieran entre sí
más allá de una cantidad especificada.
Carlos Figueira/USB
24
Exclusión Mutua Distribuida
¿Ideas?
Carlos Figueira/USB
25
Requerimientos
1. EM1 (seguridad). A lo sumo un proceso a la
vez puede ejecutar su sección crítica (SC)
2. EM2 (vitalidad).
1. (Sin bloqueo) Un proceso que requiere entrada a
su SC, en algún momento se le concederá
2. (Sin inanición) Cualquier proceso que ejecute su
SC, en algún momento saldrá de ella
3. EM3 (ordenamiento). La entrada a la SC debe
ser otorgada en el orden “pasó antes”
Carlos Figueira/USB
26
Algoritmo Centralizado
●
●
●
Si un proceso quiere entrar en su SC, envía un
mensaje de solicitud al coordinador, indicando
cuál SC requiere
Si ningún proceso está en esa SC, coordinador
envía mensaje de otorgamiento
Si hay otro proceso en la SC, encola su petición
●
●
Envía mensaje de negación, y solicitante intentará
de nuevo más tarde (espera activa) o
No envía nada, el solicitante se bloquea
Carlos Figueira/USB
27
Algoritmo Centralizado (cont.)
●
●
Si un proceso sale de la SC, envía un mensaje
notificando al coordinador
Coordinador busca siguiente petición encolada
y envía mensaje de otorgamiento
Coordinador
P4
P1
1. solicita
3. otorga
P1
P2
P2
sc1
2. libera
P3
Carlos Figueira/USB
sc2
P4
28
Algoritmo Centralizado (cont.)
●
●
Ventajas
●
Se puede generalizar para asignación de recursos
●
Es justo: peticiones atendidas en orden de solicitud
●
Requiere sólo 3 tipos de mensaje
Desventajas
●
●
●
Centralizado (punto único de falla, cuello de botella)
Si coordinador no envía respuesta ante negación, el
solicitante no sabe si respuesta no llega por negación
o por falla
¿Qué pasa si cliente falla dentro de una SC?
Carlos Figueira/USB
29
Algoritmo Distribuido: Ricart y
Agrawala
●
●
●
Cada proceso que requiere entrar a SC envía
mensaje a todos los procesos; entra sólo
cuando recibe confirmación de todos
Construye mensaje con id de SC, id. de
proceso y hora actual
Envía mensaje a todos, incluyendo a sí mismo
Carlos Figueira/USB
30
Algoritmo Ricart y Agrawala (cont.)
●
Cuando un proceso recibe mensaje de solicitud
de otro proceso:
1. Si receptor no está en esa SC y no desea entrar,
envía OK
2. Si receptor está en SC, no responde sino que
incluye solicitud en una lista
3. Si el receptor desea entrar en SC pero no lo ha
logrado, compara fecha del mensaje recibido con la
fecha del que él envió: si la suya es menor, encola
la petición; sino, envía OK
Carlos Figueira/USB
31
Algoritmo Ricart y Agrawala (cont.)
●
●
●
●
Dos procesos (0 y 2)
quieren acceder a un
recurso compartido al
mismo tiempo
El mensaje de 0 tiene
fecha 8, mientras que el
de 2 tiene fecha 12.
1 y 2 envían OK a 0, 1
envía OK a 2 también
0 entra en SC
Carlos Figueira/USB
32
Algoritmo Ricart y Agrawala (cont.)
●
●
Cuando el proceso 0
termina, envía mensaje
de OK
2 ya tenía OK de 1,
puede entrar a SC
Carlos Figueira/USB
33
Algoritmo Ricart y Agrawala:
Problemas
●
Un proceso que falla y no está en SC puede
impedir que otros entren (EM2).
●
●
●
●
No responderá a las peticiones, nadie podrá entrar
en SC => bloqueo
Pero cumple con EM1 (y EM3?)
Probabilidad de falla respecto a proceso
coordinador es n veces mayor!!
Requiere establecer el grupo (p.e., primitivas
de comunicación en grupo)
Carlos Figueira/USB
34
Algoritmo anillo de ficha (token-ring)
●
●
●
●
Los procesos se ordenan en un anillo lógico; se
usa una ficha, que se circula en el sentido de las
agujas del reloj
Si un proceso quiere entrar en SC, espera la
ficha y la retiene. Al salir de la SC, la pasa al
vecino
Si un proceso no desea entrar en SC, lo pasa al
vecino inmediatamente
Se requieren 1 a n-1 mensajes para obtener
ficha
Carlos Figueira/USB
35
Algoritmo anillo de ficha (token-ring)
Un grupo de procesos desordenados en red (a)
se ordena como un anillo lógico por software (b)
Carlos Figueira/USB
36
Algoritmo anillo de ficha (token-ring)
●
Ventajas
●
●
Requiere menos mensajes que algoritmo
distribuido
Desventajas
●
No cumple con EM3 (ordenamiento)
●
Si un proceso falla hay que rehacer el anillo
●
Si falla el proceso que tiene la ficha, se debe crear
una nueva ficha (¿Qué pasa si hay más de una
ficha? ¿Puede ocurrir?)
Carlos Figueira/USB
37
Elección de coordinador o líder
Carlos Figueira/USB
38
Coordinador o líder
●
●
Muchos sistemas cliente/servidor requieren un
líder o coordinador (o servidor)
El rol de coordinador debe ser dinámico. Si
falla el actual, debe nombrarse otro
Carlos Figueira/USB
39
Algoritmos de elección de
coordinador
●
●
Una elección es un procedimiento para
seleccionar un proceso de un grupo para que
ejecute algunas operaciones específicas:
●
Nuevo coordinador
●
Tomar responsabilidad de proceso que falló
Requerimientos
●
●
Debe elegirse un único proceso, aun cuando varios
procesos llamen simultáneamente a elección
Todos deben enterarse de cuál proceso fue electo
Carlos Figueira/USB
40
Algoritmo del grandulón (bully)
●
●
●
●
Puede ser usado cuando los miembros del
grupo conocen identidades y direcciones de los
otros procesos
El
algoritmo
selecciona
el
proceso
sobreviviente con el identificador mayor
Se asume comunicación confiable, pero
procesos pueden fallar durante una elección
Tres tipos de mensajes: elección, respuesta y
coordinador
Carlos Figueira/USB
41
Algoritmo del grandulón
●
●
Una elección puede ser iniciada por cualquier
proceso que detecte que el coordinador ha fallado
Proceso P envía mensaje elección a todos aquellos
procesos que tengan un id más alto que el suyo, y
espera mensaje de respuesta:
●
●
Si no le llega ningún mensaje respuesta en un tiempo
determinado, P se nombra coordinador y envía mensaje
coordinador a todos los procesos con id menores,
anunciándose como coordinador
Si le llega al menos una respuesta, espera un tiempo
determinado por un mensaje coordinador. Sino, inicia una
nueva elección
Carlos Figueira/USB
42
Algoritmo del grandulón
●
●
●
Si un proceso recibe mensaje coordinador,
registra el id y comenzará a comunicarse con él
cuando requiera sus servicios
Si un proceso recibe mensaje de elección,
envía respuesta y comienza nueva elección
Cuando un proceso que falló se recupera,
comienza una elección aunque coordinador no
haya fallado
Carlos Figueira/USB
43
Algoritmo del grandulón
(a) Proceso 4 inicia elección. (b). Procesos 5 y 6
responden, indicando a 4 que se detenga. (c) 5 y
6 inician cada uno una elección
Carlos Figueira/USB
44
Algoritmo del grandulón
(d) Proceso 6 dice a 5 que se detenga. (e).
Proceso 6 gana y lo comunica a todos los demás
Carlos Figueira/USB
45
Algoritmo del grandulón
●
En el mejor caso, el proceso con el segundo
mayor id se da cuenta de la falla del
coordinador, inicia una elección:
●
●
sólo se envían n-2 mensajes coordinador
Peor caso: proceso con menor id se da cuenta
de la falla del coordinador, inicia una elección.
Se requieren O(n2) mensajes
Carlos Figueira/USB
46
Algoritmos basados en anillos
lógicos
●
Propuesto por Gerard Le Lann (76), mejorado por Chang y
Roberts (79).
●
●
●
●
●
Cada proceso tiene id único y conoce el id del vecino
Cualquier proceso puede querer ser coordinador (“rojo”), e iniciar
elección, enviando mensaje a su vecino con su id indicando que
quiere ser coordinador. Sino, se marca como “negro”.
Si un proc. rojo recibe mensaje antes de iniciar elección, pasa a
negro (un proc. negro nunca se vuelve rojo)
Los nodos pueden fallar. Si el vecino falló, el mensaje es enviado al
siguiente vecino activo
Se elige como coordinador el de mayor id que participa en elección
Carlos Figueira/USB
47
Algo. de Chang y Roberts
Inicialmente: todos los procesos son rojos, y proc i envía elecc<i>
a su vecino. Cada proc i ejecuta
recv (mens(elecc<x>))
Si (color=rojo) entonces /* participa en elección */
Si (x < i) entonces descartar mens
Sino si (x > i) entonces send(elecc<x>) ; color:= negro
/*abandona*/
Sino si (x = i) entonces L(i) :=i ; send(coord<i>)
/*i es coordinador, el mensaje da la vuelta al anillo*/
Fin Si
Sino Si (color=negro) entonces send(elecc<x>) /* no participa en
elección */
Fin Si
Carlos Figueira/USB
48
Complejidad Algo. de Chang y
Roberts
●
Peor caso en número de mensajes
●
●
●
●
●
Todos inician elección
Anillo numerado en orden inverso al del sentido de
circulación de mensajes
Mensaje de proc k hace un máx de k+1 saltos
(reenvíos).
Para n procesos, 1+2+3...+n= n(n+1)/2
Al final hay un mensaje adicional para anunciar el
nuevo coordinador
Carlos Figueira/USB
49
Anexos
Carlos Figueira/USB
50
Variantes algoritmos de elección
●
●
Mejoras al algoritmo de Chang y Roberts:
●
Recordar mayor id visto; si recibe uno menor, no reenvía
●
Anillos bi-direccionales (Franklyn)
En general
●
●
●
●
Para árboles, algoritmos del estilo “olas”
Para anillos, Chang/Roberts
Para grafos: variante de algoritmo de construcción de
árbol
Problema anillo, árbol: sensibles al fallo de nodos
(hay que reconstruir la topología)
Carlos Figueira/USB
51
Redes anónimas
●
Puede no conocerse los id, o no son únicos
●
El tamaño de la red puede ser calculado si el coordinador existe
●
Id únicos pueden ser distribuidos si existe un coordinador
●
●
●
Es imposible construir un algoritmo determinístico de elección sin
un coordinador
Algorítmicos probabilísticos usando números aleatorios
– Usar algoritmos de árbol para escoger un coordinador
Ejemplos: redes de sensores, o Computadores MIMD
Carlos Figueira/USB
52
Redes de sensores
Carlos Figueira/USB
53
Referencias
●
●
Sukumar Ghosh. “Distributed systems: an
algorithmic approach”, Volumen 13 de
Chapman & Hall/CRC computer and
information science series, CRC Press, 2007
Material del Profesor Ali Ghodsi, del KTH Inst.
of Technology, Suecia http://www.scse.se/~ali
Carlos Figueira/USB
54