04 - Algoritmos Distribuidos - IIC2523

Transcripción

04 - Algoritmos Distribuidos
IIC2523 - Sistemas Distribuidos
Cristian Ruz – [email protected]
Departamento de Ciencia de la Computación
Pontificia Universidad Católica de Chile
Semestre 1-2013
C.Ruz (PUC)
IIC2523
1/2013
1 / 115
Contenidos
1
Estados Globales y Tiempo
Relojes, eventos y estados
Sincronización de Relojes
Relojes y Vectores Lógicos
Estados Globales
2
Exclusión Mutua y Consenso
Exclusión Mutua Distribuida
Elección y Consenso
3
Transacciones
4
Tolerancia a Fallas y Replicación
C.Ruz (PUC)
IIC2523
1/2013
2 / 115
Algoritmos Distribuidos
Conceptos fundamentales algorı́tmicos
Independiente de tecnologı́as particulares
Modelo de ejecución particular:
Se ejecutan en procesadores independientes
Toman decisiones basados en información local
No poseen toda la información del sistema
No hay una fuente precisa de tiempo global
C.Ruz (PUC)
IIC2523
1/2013
3 / 115
Contenidos
1
Estados Globales
2
3
Transacciones
4
C.Ruz (PUC)
IIC2523
1/2013
4 / 115
La importancia del tiempo
Para muchas aplicaciones es importante conocer el tiempo en que se
ejecutó alguna instrucción (o evento).
Timestamps para:
Consistencia
Sincronización
Prevención de duplicados
Compilación automática (make)
...
C.Ruz (PUC)
IIC2523
1/2013
5 / 115
Necesitamos medir el tiempo
Pero no es tan fácil medir el tiempo, ¿por qué?
Teorı́a Especial de la Relatividad
Observaciones de eventos son relativas
Dos eventos simultáneos en un marco de referencia no lo son
necesariamenete para observadores en otro marco de referencia.
Entonces, ¿nada que hacer?
Dos eventos pueden ser vistos en distintos orden por distintos
observadores.
Al menos para eventos independientes
¿Y si uno provoca el otro?
El tiempo entre causa y efecto puede variar, pero no el orden.
C.Ruz (PUC)
IIC2523
1/2013
6 / 115
Pero estamos hablando de computadores . . .
. . . que no viajan a la velocidad de la luz
¿Cómo generar timestamps precisos en nodos distintos?
Para dos eventos e1 , e2 ,
¿cuál ocurrió primero?
¿ocurrieron “simultáneamente”?
¡No hay un reloj global!
Sin embargo,. . . los algoritmos funcionan . . .
Dos problemas
Sincronizar relojes usando paso de mensajes
Observación del estado global de un sistema distribuido
C.Ruz (PUC)
IIC2523
1/2013
7 / 115
Modelo
Consideramos un sistema distribuido como una colección P de N procesos
pi , con i = 1, 2, . . . , N.
Cada proceso pi ejecuta en un procesador independiente
Suponemos que no hay memoria compartida
Sólo se comunican por paso de mensajes: send y recv
Cada proceso pi tiene un estado si que cambia durante la ejecución.
Evento
Ocurrencia de una acción individual
send, recv u otra acción que cambie el estado del pi
C.Ruz (PUC)
IIC2523
1/2013
8 / 115
Historia
Los eventos dentro de pi poseen un orden total, definido por la relación →i
Relación ocurre antes
e1 →i e2 ⇔ e1 ocurre antes que e2 en pi .
Ahora es posible definir la historia del proceso pi
Historia de pi
Serie de eventos que ocurren en pi definidos por la relación →i
history (pi ) = hi = hei0 , ei1 , ei2 , . . .i
C.Ruz (PUC)
IIC2523
1/2013
9 / 115
Relojes
¿Y cómo se asignan esos timestamps?
CPUs poseen relojes fı́sicos
Objetivo: medir el tiempo real t
Conteo de oscilaciones de un cristal de frecuencia estable
Cada dosc se incrementa un registro: hardware clock Hi (t)
S.O. produce un software clock: Ci (t) = αHi (t) + β, que aproxima t
Cada evento que ocurre en tiempo t en pi recibe el timestamp Ci (t)
El marco de tiempo (timeframe) de Ci (t) debe ser suficientemente
corto para que dos eventos sucesivos e, e 0 reciban timestamps distintos.
Al menos e y e 0 no pueden tener un ∆t menor que el tiempo mı́nimo
de un ciclo de instrucciones.
C.Ruz (PUC)
IIC2523
1/2013
10 / 115
Relojes
Distorsión (skew) y desviación (drift)
Pero los relojes no son perfectos.
Para dos relojes distintos:
Skew. Diferencia entre lecturas simultáneas de ambos relojes.
Drift. Desviación o divergencia producto del ritmo de conteo.
Algunos números
Relojes basados en cristales de cuarzo. Drift 10−6 segundos por cada
segundo real.
1 segundo cada 1000000 segundos reales (11, 6 dı́as)
¿Mucho o poco?
Relojes de “alta precisión”: 10−7 a 10−8 segundos por cada segundo
real.
Relojes atómicos: 10−13
C.Ruz (PUC)
IIC2523
1/2013
11 / 115
Relojes
Tiempo Coordinado Universal: UTC
Una solución: sincronización con fuentes externas “confiables”
International Atomic Time (IAT): medido con relojes atómicos
1 segundo (desde 1967)
1 segundo se define como 9192631770 oscilaciones de la radiación emitida
en la transición entre dos niveles hiperfinos del estado fundamental del
isótopo 133 de un átomo de Cesio (133 Cs) a una temperatura de 0o K
Antes de 1967: definido por rotación y traslación de la Tierra.
UTC = Time Coordinated Universal Time = Temps Universel Coordonné
Basado en IAT + leap seconds1
Emitido de señales terrestres y satelitales (incluyendo GPS time)
Precisión ∼ 0.1 − −10 msec (tierra), ∼ 1µsec satelital
1
25 agregados desde 1972. El último en June 30, 2012 at 23:59:60 UTC
C.Ruz (PUC)
IIC2523
1/2013
12 / 115
Sincronizando Relojes Fı́sicos
Dos estilos de sincronización: externa . . . e interna
D > 0 es un cota de sincronización, y S es una fuente de tiempo UTC.
Sincronización externa
|S(t) − Ci (t)| < D, para i = 1, 2, . . . N, para todo tiempo real t.
Los relojes Ci son precisos hasta la cota D.
Sincronización interna
|Ci (t) − Cj (t)| < D, para i, j = 1, 2, . . . N, para todo tiempo real t.
Los relojes concuerdan hasta una cota D.
Sincronización interna no implica necesariamente sincronización externa.
(¿Por qué?)
Si el sistema está sincronizado externamente hasta D, ¿qué se puede decir
de la sincronización interna?
C.Ruz (PUC)
IIC2523
1/2013
13 / 115
Noción de correctitud.
Correctitud
Reloj es correcto si su desviación está acotada por ρ > 0. Al medir dos
tiempos reales t y t 0 (t 0 > t):
(1 − ρ)(t 0 − t) ≤ H(t 0 ) − H(t) ≤ (1 + ρ)(t 0 − t)
También suponemos monotonı́a
Monotonı́a
El reloj solamente avanza.
t 0 > t ⇒ C (t 0 ) > C (t)
C.Ruz (PUC)
IIC2523
1/2013
14 / 115
Problema de Sincronización Interna
Ttrans , tiempo requerido para transmitir mensaje m
pi envı́a t y pj establece su reloj en t + Ttrans
En general no conocemos Ttrans
Se puede estimar por min < Ttrans < max
u = (max − min)
Si pj establece su reloj en t + min, el desfase máximo será a lo más u
Si pj establece su reloj en t + max, el desfase máximo será a lo más u
¿Y si lo establece en t + (max − min)/2? → u/2
Lundelius & Lynch, 1984
La mejor cota que se puede obtener para sincronizar N relojes es
u(1 − N1 )
En la práctica es difı́cil establecer max, y se usa Ttrans = min + x, x ≥ 0
C.Ruz (PUC)
IIC2523
1/2013
15 / 115
Algoritmo de Cristian (1989)
Método de sincronización externa.
No hay una cota superior para Ttrans en un sistema ası́ncrono.
Algoritmo funciona mientras el round-trip es suficientemente corto
comparado a la precisión requerida.
p solicita el tiempo en un mensaje mr , y recibe en t en el mensaje mt .
p cuenta el tiempo entre el envı́o de mr y la recepción de mt : Tround
p estima el tiempo real como t + Tround /2.
C.Ruz (PUC)
IIC2523
1/2013
16 / 115
¿Precisión?
t podrı́a corresponder a cualquier momento del rango h
Intervalo de recepción de tm : [t + min, t + min + h]
h = Tround − 2min
p
t0
S
mr
min
t
T round
mt
?
h
min
t1
Intervalo de recepción de tm : [t + min, t + Tround − min]
Desviación: ±(Tround /2 − min)
Desviación depende de min
C.Ruz (PUC)
IIC2523
1/2013
17 / 115
Debilidades:
Servicio centralizado
Alternativa: consultar un grupo de servidores sincronizados
Congestión en la red incrementa el tiempo de propagación
Estimar min usando consultas repetidas
Servidor malicioso
Múltiples servidores + votación
C.Ruz (PUC)
IIC2523
1/2013
18 / 115
Algoritmo de Berkeley (Gusella & Zatti, 1989)
Sincronización interna de pi , i = 1, 2, . . . N
Un proceso en particular, pM tiene el rol de master2
pM solicita tiempos Ci (t) para cada proceso
Estimaciones usando el algoritmo de Cristian
pM calcula un tiempo promedio t̄
Cálculo puede utilizar un umbral de tiempo de transmisión max y
descartar algunos valores
pM envı́a a cada pi su desviación respecto a t̄
2
Elección de lı́deres a ver en sección 4.2
C.Ruz (PUC)
IIC2523
1/2013
19 / 115
Network Time Protocol (NTP), 1995
Cristian y Berkeley diseñados para redes de baja latencia (p.e., LAN)
Basado en redes de servidores, agrupados por niveles
Niveles,
Nivel 1:
Nivel 2:
Nivel 3:
llamados estratos, representan grados de precisión
conectados a fuentes directas (radio, atómicas)
sincronizados de acuerdo a nivel 1
sincronizados de acuerdo a nivel 2, . . .
Servidores pueden cambiar de estrato si pierden conectividad
Tres modos de sincronización:
Multicast. Transmisión directa de servidor a clientes (LAN). Supone
bajo delay. Baja precisión.
Procedure-call. Clientes consultan servidores (como algoritmo de
Cristian). Mayor precisión.
Symmetric. Intercambios entre servidores del mismo estrato.
C.Ruz (PUC)
IIC2523
1/2013
20 / 115
C.Ruz (PUC)
IIC2523
1/2013
21 / 115
Mensajes intercambian 4 timestamps: Ti−3 , Ti−2 , Ti−1 , Ti
NTP estima un offset oi y un delay di
t y t 0 : tiempos reales para transmitir m y m0 , o: offset real
Ti−2 = Ti−3 + t + o, Ti = Ti−1 + t 0 − o
Delays: di = t + t 0 = (Ti−2 − Ti−3 ) + (Ti − Ti−1 )
Offset: o = oi + (t 0 − t)/2, donde oi = (Ti−2 − Ti−3 + Ti−1 − Ti )/2
Se puede demostrar que:
oi − di /2 ≤ o ≤ oi + di /2
Calcula varios pares hoi , di i y utiliza los 8 más recientes
C.Ruz (PUC)
IIC2523
1/2013
22 / 115
Relaciones causales
Lamport, 1978
Precisión de relojes fı́sicos tiene un lı́mite
Sincronización perfecta es imposible en un sistema distribuido
Pero dentro de un mismo proceso sı́ hay un orden absoluto
Usar causalidad para establecer órdenes entre distintos procesos
Dos observaciones importantes:
Dos eventos e1 y e2 que ocurren en pi están relacionados por →i
Un evento send en un proceso i necesariamente ocurre antes que el
correspondiente recv en el proceso j
Lamport usa ambas observaciones para definir la relación ocurre antes
entre eventos de distintos procesos
C.Ruz (PUC)
IIC2523
1/2013
23 / 115
Relación ocurre-antes (happens-before)
Lamport, 1978
A.K.A. ordenamiento causal, u ordenamiento potencialmente causal
Relación ocurre-antes: →
HB1: Si ∃pi : e →i e 0 , entonces e → e 0
HB2: ∀ mensaje m, send(m) → recv (m)
HB3: Para los eventos e, e 0 , e 00 , se cumple que
e → e 0 ∧ e 0 → e 00 ⇒ e → e 00
C.Ruz (PUC)
IIC2523
1/2013
24 / 115
Relación ocurre-antes (happens-before)
Lamport, 1978
¿Qué relaciones se dan?
HB1: a → b, c → d, e → f
HB2: b → c, d → f
HB3: a → c, a → f , c → f , . . .
No hay un orden total
a 6→ e y e 6→ a
a y e son concurrentes: a k e
C.Ruz (PUC)
IIC2523
1/2013
25 / 115
Relojes Lógicos
Lamport, 1978
Un reloj lógico es un contador monótono creciente
Cada proceso pi mantiene su propio reloj lógico Li
Sin relación con el reloj fı́sico
Usado para establacer Lamport Timestamps
Li (e), timestamp del evento e en pi
L(e), timestamp del evento e en el proceso en que ocurrió
C.Ruz (PUC)
IIC2523
1/2013
26 / 115
Relojes Lógicos
Lamport, 1978
Relojes lógicos se actualizan para capturar la relación ocurre-antes
Actualización de Relojes Lógicos
LC1: Li se incrementa antes de cada evento en pi :
Li := Li + 1
LC2a: Cuando pi hace send(m), agrega el valor t = Li
LC2b: Cuando pj recibe el par (m, t), actualiza:
Lj := max(Lj , t)
y
aplica LC1 antes de aplicar un timestamp a recv (m)
Para pensar (I): se puede demostrar que e → e 0 ⇒ L(e) < L(e 0 ),
independiente del incremento que se use.
Para pensar (II): ¿es cierto que L(e) < L(e 0 ) ⇒ e → e 0 ?
C.Ruz (PUC)
IIC2523
1/2013
27 / 115
Relojes Lógicos
Lamport, 1978
C.Ruz (PUC)
IIC2523
1/2013
28 / 115
Relojes Lógicos
Lamport, 1978
C.Ruz (PUC)
IIC2523
1/2013
29 / 115
Orden total con relojes lógicos
Lamport, 1978
Algunos eventos en distintos procesos tienen el mismo timestamp
¿Problema?
Es normal si son concurrentes
¿ Y si son entradas a secciones crı́ticas?
Solución arbitraria (pero efectiva)
Reemplazar el timestamp Ti de e en pi por (Ti , i)
Para dos timestamps (Ti , i) y (Tj , j), se define:
(Ti , i) < (Tj , j) ⇔ Ti < Tj ∨ (Ti = Tj ∧ i < j)
C.Ruz (PUC)
IIC2523
1/2013
30 / 115
Relojes Vectoriales
Mattern (1989), Fidge (1991)
Un Reloj Vectorial para N procesos, es un vector N-dimensional.
Cada proceso mantiene su reloj vectorial Vi , y marca sus eventos.
Al hacer send(m), se agrega Vi
Actualización de Relojes Lógicos
VC1: Inicialmente: Vi [j], para i, j = 1, 2, . . . , N
VC2: Vi se actualiza antes de cada evento en pi : Vi [i] := Vi [i] + 1
VC3: Cuando pi hace send(m), agrega el valor t = Vi
VC4: Cuando pi recibe el par (m, t), actualiza:
Vi [j] := max(Vi [j], t[j]), para j = 1, 2, . . . , N
y
aplica VC2 antes de aplicar un timestamp a recv (m)
C.Ruz (PUC)
IIC2523
1/2013
31 / 115
Relojes Vectoriales
C.Ruz (PUC)
IIC2523
1/2013
32 / 115
Relojes Vectoriales
¿Hay algún significado en estos valores?
Vi [i], número de eventos marcados por pi
Vi [j], j 6= i, número de eventos marcados en j que podrı́an haber
afectado pj (potencialmente relacionados con pj )
¿Cómo se comparan dos vectores V y V 0 ?
V = V 0 ⇔ V [j] = V 0 [j], para j = 1, 2, . . . N
V ≤ V 0 ⇔ V [j] ≤ V 0 [j], para j = 1, 2, . . . N
V < V 0 ⇔ V ≤ V 0 ∧ V 6= V 0
e k e 0 . . . cuando V (e) 6≤ V (e 0 ) y V (e) 6≥ V (e 0 )
Para pensar (III): Se puede demostrar que e → e 0 ⇒ V (e) < V (e 0 )
Para pensar (IV): ¿Se puede demostrar que V (e) < V (e 0 ) ⇒ e → e 0 ?
C.Ruz (PUC)
IIC2523
1/2013
33 / 115
Relojes Vectoriales
Debilidades:
Almacenamiento y envı́o O(N)
Charron-Bost (1991) demuestra que para determinar la relación
ocurre-antes usando timestamps, es necesario utilizar las N
dimensiones
Raynal & Singhal (1996) indicando maneras de enviar menos
información, a cambio de un overhead dentro de cada proceso para
reconstruir los vectores.
Relojes Matriciales: mantienen estimaciones de relojes vectoriales de
los N procesos.
C.Ruz (PUC)
IIC2523
1/2013
34 / 115
Estados Globales
Propiedades globales
Problema: determinar algunas propiedades en sistemas distribuidos
¿Hay referencias externas a un objeto local?
Recolección de basura distribuida
Contador local es 0, pero puede haber referencias “en camino”.
¿Está el sistema en un estado de bloqueo mutuo?
Detección de deadlock distribuido
¿Ha terminado el algoritmo distribuido?
No es un halting problem distribuido
Detección de terminación distribuida
Todos los procesos pueden estar detenidos ... pero puede haber un
mensaje en camino
C.Ruz (PUC)
IIC2523
1/2013
35 / 115
Estados Globales
Propiedades globales
C.Ruz (PUC)
IIC2523
1/2013
36 / 115
Estados Globales
¿Cómo coleccionar un estado global?
Definiciones
El gran problema: la ausencia de tiempo global
Algunas definiciones:
history (pi ) = hi = hei0 , ei1 , ei2 , . . .i
Prefijo finito de historia: hik = hei0 , ei1 , ei2 , . . . , eik i
Estado de pi antes del k-ésimo evento: sik . Estado inicial: si0 .
Historia global de P: H = h0 ∪ h1 ∪ . . . ∪ hN−1
Estado global: S = (s1 , s2 , . . . , sN )
No cualquier conjunto de estados tiene sentido
Corte: subconjunto de la historia global
cN
C = h1c1 ∪ h2c2 ∪ . . . ∪ hN
Frontera del corte: eventos {eici : i = 1, 2, . . . N}
C.Ruz (PUC)
IIC2523
1/2013
37 / 115
Estados Globales
Definiciones
Fronteras he10 , e20 i, he12 , e22 i
Corte inconsistente: incluye recepción de m pero no su envı́o.
Corte consistente: incluye envı́o y recepción, o bien sólo envı́o.
Corte consistente C : ∀e ∈ C , f → e ⇒ f ∈ C
Por cada evento, también están los que ocurrieron antes que él.
Un corte consistente define un estado global consistente
La ejecución se puede caracterizar por una secuencia de estados
globales consistentes
S0 → S1 → S2 → . . .
C.Ruz (PUC)
IIC2523
1/2013
38 / 115
Estados Globales
Y más definiciones
Run: Orden total de eventos, que es consistente con las historias
locales hi
Linearización ó Run consistente: Orden de eventos de una historia
global que es consistente con la relación ocurre antes.
Una linearización también es un run.
No todos los runs pasan por estado globales consistentes.
Una linearización solo pasa por estados globales consistentes.
C.Ruz (PUC)
IIC2523
1/2013
39 / 115
Estados Globales
Algoritmo de snapshot: Chandy y Lamport (1985)
Permite observar estados globales consistentes
Captura estados de procesos y de canales de comunicación.
Los estados capturados pueden no haber ocurrido conjuntamente en el
sistema, sin embargo el conjunto define un estado global consistente
Algunos supuestos:
Cada proceso pi es capaz de grabar su estado local
Canales confiables: todos los mensajes enviados son recibidos en
algún momento
Canales unidireccionales y entrega FIFO
El grafo de procesos y canales está fuertemente conectado
El algoritmo puede ser iniciado por cualquier proceso
Los procesos pueden continuar su ejecución concurrentemente con el
algoritmo de snapshot
C.Ruz (PUC)
IIC2523
1/2013
40 / 115
Estados Globales
Algoritmo de Chandy y Lamport (1985)
Idea general
Cada pi almacena:
Su estado
Los mensajes recibidos por cada canal de entrada
Para cada canal de entrada, pi almacena:
Los mensajes recibidos después de haber guardado su estado si , y antes
que el sender guardara su propio estado.
Ejemplo: Si pi envı́a m a pj , pero pj no lo ha recibido, entonces m es
parte del estado del canal entre pi y pj
El algoritmo usa mensajes marker
Indica al receptor que debe guardar su estado, si aún no lo ha hecho
Permite determinar los mensajes que deben ser incluidos en el estado
del canal
C.Ruz (PUC)
IIC2523
1/2013
41 / 115
Estados Globales
Mensajes marker
Recepción de marker en el proceso pi , por el canal c
1 if (p no ha guardado su estado)
i
1
2
3
2
pi guarda su estado
pi establece el estado de c como sc = ∅
pi empieza a guardar los mensajes de todos sus canales de entrada
else
1
pi guarda en el estado sc todos los mensajes recibidos en c desde que
pi guardó su estado
La primera vez obliga a un proceso a guardar su estado, y guarda los
mensajes en cada canal
Desde la segunda recepción de un marker, guarda los mensajes
recibidos en cada canal
C.Ruz (PUC)
IIC2523
1/2013
42 / 115
Estados Globales
Mensajes marker
Envı́o de markers en el proceso pi
1 Luego de haber guardado su estado, para cada canal de salida c:
1
pi envı́a un marker a través de c, antes de enviar cualquier otro
mensaje a través de c
Cualquier proceso pi puede iniciar el algoritmo.
pi comienza como si hubiese recibido un marker a través de un canal
inexistente
Puede haber más de una instancia del algoritmo ejecutándose, iniciada por
distintos procesos
Solo se necesita ser capaz de distinguir los markers.
C.Ruz (PUC)
IIC2523
1/2013
43 / 115
Estados Globales
Ejemplo
C.Ruz (PUC)
IIC2523
1/2013
44 / 115
Contenidos
1
Estados Globales
2
3
Transacciones
4
C.Ruz (PUC)
IIC2523
1/2013
45 / 115
Dos problemas
Exclusión Mutua Distribuida Coordinación de procesos para compartir
recursos. Evitar race conditions. Selección de procesos.
Consenso Alcance de acuerdo en presencia de fallas o procesos
“maliciosos” (bizantinos).
C.Ruz (PUC)
IIC2523
1/2013
46 / 115
Solución centralizada
Un proceso funciona como lock master, y entrega locks de acceso a
secciones crı́ticas.
Factible hasta cierta cantidad de procesos.
Solución distribuida
No siempre es posible designar un lock master
Ejemplo: Redes ethernet ó wifi ’ad-hoc’: sólo un nodo debe transmitir
a través del medio
Tres algoritmos
Ring-based
Ricart-Agrawala (1981)
Maekawa (1985)
C.Ruz (PUC)
IIC2523
1/2013
47 / 115
Modelo
N procesos: pi , i = 1, 2, . . . , N
Sin variables compartidas
Sistema ası́ncrono
Procesos no fallan
Red confiable (mensajes son entregados exactly-once)
Condiciones de correctitud para exclusión mutua
ME1. Safety : A lo más un proceso se encuentra en la sección crı́tica
simultáneamente.
ME2. Liveness : Todo proceso que quiere entrar la sección crı́tica lo
consigue en algún momento.
No hay deadlock ni starvation
ME3. Orden → . Una solicitud de entrada a sección crı́tica a es
atendida antes que una solicitud b si es que a → b.
C.Ruz (PUC)
IIC2523
1/2013
48 / 115
Algoritmo con Servidor Central
Master recibe solicitudes de acceso y responde en orden FIFO
La respuesta es un token de acceso
El proceso que sale de su sección crı́tica debe devolver el token
Mientras alguien tenga el token, procesos son encolados
C.Ruz (PUC)
IIC2523
1/2013
49 / 115
Algoritmo con Servidor Central
#mensajes:
2 mensajes para entrar (request + grant) y 1 para salir (release)
Delay: tiempo entre un release y un grant
Desventaja
Cuello de botella en el master
C.Ruz (PUC)
IIC2523
1/2013
50 / 115
Algoritmo Ring-based
Procesos organizados en un anillo lógico
pi sólo puede enviar mensajes a p(i+1)
mod N
Cuando pi recibe el token
Si no lo necesita, lo reenvı́a a p(i+1) mod N
Si lo necesita, lo conserva. Al liberarlo, lo reenvı́a a p(i+1)
C.Ruz (PUC)
IIC2523
mod N
1/2013
51 / 115
Algoritmo Ring-based
#mensajes:
Entre 0 y N, más 1 mensajes para salir.
Delay entre dos accesos: entre 1 y N mensajes
Desventajas
Consume ancho de banda innecesariamente (cuando nadie lo necesita)
C.Ruz (PUC)
IIC2523
1/2013
52 / 115
Algoritmo de Ricart y Agrawala (1981)
Procesos hacen multicast a los demás
Cada proceso pi mantiene un reloj lógico Li
Mensajes de entrada incluyen hLi , pi i
Procesos poseen un estado:
RELEASED. Se encuentra fuera de sección crı́tica
WANTED. Desea entrar a sección crı́tica
HELD. Se encuentra dentro de sección crı́tica
C.Ruz (PUC)
IIC2523
1/2013
53 / 115
C.Ruz (PUC)
IIC2523
1/2013
54 / 115
C.Ruz (PUC)
IIC2523
1/2013
55 / 115
Inicialmente, ∀i, Spi = RELEASED
Cuando pi quiere entrar a la sección crı́tica:
Spi = WANTED
Envı́a multicast a todos, con timestamp Li
Esperar hasta recibir N − 1 respuestas
Entra, y Spi = HELD
Cuando pj recibe una solicitud de acceso hLi , pi i
IF (Spj == HELD) OR (Spj == WANTED AND (Lj , pj ) < (Li , pi ))
Encolar (Li , pi ) y no responder
ELSE
Responder a pi autorizando acceso
Cuando pi sale de la sección crı́tica
Spi = RELEASED
Responder a todas las solicitudes encoladas
C.Ruz (PUC)
IIC2523
1/2013
56 / 115
#mensajes:
(N − 1) para pedir acceso, y (N − 1) respuestas
Delay: 1 mensaje.
Desventajas:
Cantidad de mensajes O(N)
C.Ruz (PUC)
IIC2523
1/2013
57 / 115
Algoritmo de Maekawa (1985)
Observación: se debe pedir acceso a todos
Es posible pedir acceso sólo a un subconjunto
Siempre que los subconjuntos se traslapen
Proceso se convierten en candidatos que recolectan votos
Procesos en la intersección de los subconjuntos ayudan a discriminar
Cada proceso tiene un voting set Vi ⊆ {p1 , p2 , . . . , pN }, construidos de
manera que:
pi ∈ Vi
Vi ∩ Vj 6= ∅
|Vi | = K
Cada proceso pi pertenece a M conjuntos Vi
√
Solución óptima se obtiene con K ∼ N, y M = K
C.Ruz (PUC)
IIC2523
1/2013
58 / 115
C.Ruz (PUC)
IIC2523
1/2013
59 / 115
Inicialmente: ∀i, Spi = RELEASED, voted i = FALSE
Cuando pi quiere entrar a la sección crı́tica:
Spi = WANTED
Envı́a multicast a Vi
Espera hasta recibir K respuestas
Entra, y Spi = HELD
Cuando pj recibe una solicitud de pi
IF (Spj == HELD) OR voted j = TRUE )
Encolar solicitud de pi y no responder
ELSE
Responder a pi autorizando acceso
voted i = TRUE
Cuando pi sale de la sección crı́tica
Spi = RELEASED
Envı́a mensaje release a todos los miembros de Vi
C.Ruz (PUC)
IIC2523
1/2013
60 / 115
Cuando pj recibe un mensaje de release desde pi
IF hay mensajes encolados
pk = dequeue()
Responder a pk
voted = TRUE
ELSE
voted = FALSE
#mensajes
√
2√N para entrar, y
3 N < 2(N − 1)
Delay: 2 mensajes
√
N para salir
Desventajas
Puede producir deadlock (¿cómo?)
Puede solucionarse
introduciendo prioridades, al costo de aumentar los
√
mensajes a 5 N
C.Ruz (PUC)
IIC2523
1/2013
61 / 115
Algoritmos de Elección
¿Para qué?
Algoritmos en que un proceso cumple un rol particular.
Caı́da del proceso master
Cualquier otro par podrı́a tomar su rol
Pero todos deben estar de acuerdo
Cualquier proceso que detecte la desaparición del master puede iniciar
la elección
Podrı́a haber N elecciones simultáneas
pi tiene una variable: participante o no-participante
pi tiene una variable: elected i , con el lı́der elegido por pi , o el valor
null
Criterio: elegir el proceso con mayor id
Generalidad: id puede ser definido de cualquier manera
1/load, totalMemory, nCores, . . .
C.Ruz (PUC)
IIC2523
1/2013
62 / 115
Algoritmos de Elección
Requisitos
E1. Safety Un proceso participante pi tiene elected i == null, ó
elected i == P, donde P es el proceso con mayor id
E2. Liveness Todos los procesos pi participan de la elección y llegan, en
algún momento a elected i 6= null.
C.Ruz (PUC)
IIC2523
1/2013
63 / 115
Algoritmo Ring-based de Chang y Roberts (1979)
Inicialmente, ∀pi , participant i = FALSE
Cuando pi inicia una elección
participant i = TRUE
Agrega id i a un mensaje election, y lo envı́a a p(i+1)
Cuando pj recibe un mensaje election con id k
IF id j > id k
mod N
IF participant j == FALSE
Reenvı́a mensaje election, pero con id j
participant j = TRUE
ELSE
Reemplaza id k por id j , pero no reenvı́a
ELSE IF id j < id k
Reenvı́a mensaje election
participant j = TRUE
ELSE (id j == id k )
Envı́a mensaje elected con id j
participant j = FALSE
elected j = id j
C.Ruz (PUC)
IIC2523
1/2013
64 / 115
Cuando pj recibe un mensaje elected con id k
participant j = FALSE
elected j = id k
IF id j 6= id k
Reenvı́a mensaje elected
C.Ruz (PUC)
IIC2523
1/2013
65 / 115
#mensajes:
Peor caso: el lı́der es el vecino anterior a quien inicio la elección
N − 1 mensajes para encontrar al lı́der
N mensajes para que el mensaje elected regrese al lı́der
N mensajes para propagar al lı́der
Total: 3N − 1 mensajes
C.Ruz (PUC)
IIC2523
1/2013
66 / 115
Algoritmo del Matón (Bully), Garcia-Molina (1982)
Tolerante a caı́das de procesos durante la elección
pi conoce a los que tienen mayor id
pi puede comunicarse con cualquier proceso
Tres tipos de mensajes
Election. Para iniciar una elección.
Answer. Respuesta un mensaje election.
Coordinator. Mensaje para anunciar al lı́der.
C.Ruz (PUC)
IIC2523
1/2013
67 / 115
Algoritmo se inicia cuando pi detecta caı́da (timeout) del lı́der.
pi inicia la elección enviando un mensaje Election a todos los que
tienen pid > pi , y espera algún mensaje Answer.
Si ninguno de ellos responde, entonces pi supone que él tiene mayor
id, y envı́a un mensaje Coordinator auto-anunciándose como nuevo
lider
Si pi recibe un Answer de lo que tiene pid > pi , entonces espera un
tiempo T para que ése proceso se anuncie como lı́der. De lo contario
reenvı́a el mensaje Election.
Si pi recibe un Election de un pid < pi , entonces responde con un
Answer, e inicia una nueva elección.
C.Ruz (PUC)
IIC2523
1/2013
68 / 115
C.Ruz (PUC)
IIC2523
1/2013
69 / 115
#mensajes:
Mejor caso: el que tiene el segundo id más grande es el único que
detecta la caı́da:
N − 1 mensajes
Peor caso: el que tiene id menor es el que detecta la caı́da
Cada uno inicia una elección: N − 1 elecciones
O(N 2 ) mensajes
Ventaja
Tolerancia a la falla de algún proceso durante la elección
C.Ruz (PUC)
IIC2523
1/2013
70 / 115
Consenso
Modelo. Dos tipos de fallas
Crash. Fallas por caı́da de un proceso.
Falla bizantina. Falla arbitraria de un proceso
Problema de Consenso
Cada proceso pi empieza con estado undecided
Cada proceso pi propone un valor vi
Los procesos pi intercambian mensajes hasta fijar una variable de
decisión di , y entrar en el estado decided. di queda fijo.
Condiciones del problema de consenso
Termination Cada proceso correcto llega a establecer su variable di
Agreement Todos los procesos correctos deciden lo mismo. Si pi y pj
son procesos correctos en estado decided, entonces di == dj
Integrity Si todos los procesos correctos proponen el mismo valor,
entonces cualquier proceso correcto llega al mismo valor.
C.Ruz (PUC)
IIC2523
1/2013
71 / 115
Consenso
Ejemplo: N procesos
Cada proceso pi elige un valor vi y lo envı́a a los demás.
Cuando cada proceso pi ha coleccionado los N valores, calcula el que
más se ha repetido, o algún valor null si no hay ninguna mayorı́a.
Todos terminan en estado decided con di = majority (v1 , v2 , . . . , vN ),
o bien di = null.
¿Qué ocurre ante una caı́da?
El algoritmo podrı́a no terminar.
¿Qué pasa si un proceso ”miente”?
Se puede llegar a consenso en un valor incorrecto
C.Ruz (PUC)
IIC2523
1/2013
72 / 115
Consenso
Problema de los Generales Bizantinos (Lamport, Shostak, Pease, 1982)
Tres o más generales deben decider entre atacar ó retirarse.
Pero uno o más de los generales pueden ser un traidor, y propagar
una orden incorrecta.
Condiciones del problema de los generales bizantinos
Termination Cada proceso correcto llega a establecer su variable di
Agreement Todos los procesos correctos deciden lo mismo. Si pi y pj
son procesos correctos en estado decided, entonces di == dj
Integrity Si el comandante es un proceso correcto, todos los procesos
correctos llegan al mismo valor propuesto por el comandante.
C.Ruz (PUC)
IIC2523
1/2013
73 / 115
Consenso
Consenso en sistemas sı́ncronos
N procesos, donde a lo más f pueden caerse durante la ejecución.
Se ejecutan f + 1 iteraciones
Cada procesos obtiene los valores de los demás
En cada iteración, los procesos correctos reenvı́an sus valores entre
ellos.
En el peor caso, un proceso se cae en cada iteración
Se necesita una iteración más para propagar los valores restantes.
Dado que el sistema es sı́ncrono, es posible detectar caı́das luego de un
timeout.
C.Ruz (PUC)
IIC2523
1/2013
74 / 115
Consenso
Consenso en sistemas sı́ncronos
C.Ruz (PUC)
IIC2523
1/2013
75 / 115
Consenso
Generales bizantinos en sistemas sı́ncronos
N procesos, donde a lo más f pueden tener fallas arbitrarias.
Caso de 3 procesos
Imposible con 3 procesos
C.Ruz (PUC)
IIC2523
1/2013
76 / 115
Consenso
Caso de N=4 procesos, y f=1 bizantino
Posible con N ≥ 3f + 1
C.Ruz (PUC)
IIC2523
1/2013
77 / 115
Consenso
#mensajes
No es posible asegurar la recepción de todos los mensajes en menos
de f iteraciones.
Se debe ejecutar al menos f + 1 iteraciones
En cada iteración cada proceso envı́a N − 1 mensajes
O(N f +1 ) mensajes
¿Mejoras?
Si los procesos firman digitalmente sus mensajes, es posible reducir el
número de mensajes a O(N 2 ) (Dolev & Strong, 1983)
C.Ruz (PUC)
IIC2523
1/2013
78 / 115
Consenso
Problema equivalente
Consistencia interactiva: obtener consenso en un vector CI i de valores
para cada proceso.
Suponiendo que hay una solución para Generales Bizantinos (BG)
Ejecutar la solución de BG N veces, en la cual cada procesos pi va
tomando el rol de comandante.
BG i (j, v ) es una solución donde pj es el comandante y entrega el
valor v .
CI i (v1 , v2 , . . . , vN )[j] = BG i (j, vj )
C.Ruz (PUC)
IIC2523
1/2013
79 / 115
Consenso
Generales bizantinos en sistemas ası́ncronos
Fischer et al.,1985: imposible garantizar consenso en un sistema
ası́ncrono, aún con una única caı́da de un proceso
Al ser ası́ncrono, es imposible distinguir una caı́da de un proceso lento
y no se puede establecer un timeout.
Sin embargo, algo se puede hacer
Enmascaramiento de fallas: utilizar almacenamiento persistente para
mantener el estado del proceso.
En caso que un proceso se caiga, puede regresar a su estado anterior.
Para los demás procesos, se ve como proceso lento (ajuste del timeout)
Utilizar detectores de fallas: establecer un proceso suficientemente
lento como fallido y descartar sus mensajes siguientes
Se transforma un sistema ası́ncrono en uno, en la práctica, sı́ncrono
Consenso bajo aleatoriedad: introducir modificaciones aleatorias en
algunos mensajes
Más que una solución para obtener consenso en el caso ası́ncrono, es
una manera evitar el éxito de un adversario bizantino.
C.Ruz (PUC)
IIC2523
1/2013
80 / 115
Transacciones
Contenidos
1
Estados Globales
2
3
Transacciones
4
C.Ruz (PUC)
IIC2523
1/2013
81 / 115
Transacciones
Transacciones
Conjunto indivisible de operaciones que mantienen un estado consistente
del sistema
ACID Properties
Atomic
Consistent
Isolated
Durable
C.Ruz (PUC)
IIC2523
1/2013
82 / 115
Transacciones
Transacciones
Operaciones básicas
transID openTransaction()
[commit,abort] closeTransaction(transID)
abortTransaction(transID)
C.Ruz (PUC)
IIC2523
1/2013
83 / 115
Transacciones
Transacciones
C.Ruz (PUC)
IIC2523
1/2013
84 / 115
Transacciones
Transacciones
Updates perdidos
Inicialmente A = $100, B = $200, C = $300
C.Ruz (PUC)
IIC2523
1/2013
85 / 115
Transacciones
Transacciones
Serialización correcta
C.Ruz (PUC)
IIC2523
1/2013
86 / 115
Transacciones
Transacciones
Lecturas inconsistentes
Inicialmente A = $200, B = $200
C.Ruz (PUC)
IIC2523
1/2013
87 / 115
Transacciones
Transacciones
Serialización correcta
C.Ruz (PUC)
IIC2523
1/2013
88 / 115
Transacciones
Serialización y operaciones conflictivas
Equivalencia Serial
La entremezcla interleaving de operaciones de dos o más transacciones es
serialmente equivalente si su efecto es el mismo de haber ejecutado cada
transacción completa en algún orden.
Transacciones Serialmente Equivalentes
Dos transacciones son serialmente equivalentes cuando las operaciones
conflictivas de ambas son ejecutadas en el mismo orden para cada objeto
¿Y cuáles son las operaciones conflictivas?
read vs write
write vs write
C.Ruz (PUC)
IIC2523
1/2013
89 / 115
Transacciones
Serialización y operaciones conflictivas
T : x = read(i); write(i, 10); write(j, 20);
U : y = read(j); write(j, 30); z = read(i);
Este interleaving no es equivalente a la ejecución T , U, ni a la ejecución
U, T
C.Ruz (PUC)
IIC2523
1/2013
90 / 115
Transacciones
Transacciones anidadas
Subtransacciones pueden hacer commit o abort de manera independiente
Una transacción hace commit ó abort solo si sus hijas han terminado.
Una subtransacción hace provisional commit ó abort
Cuando una transacción hace abort, todas sus hijas hacen abort
Si una subtransacción hace abort, el padre puede decir aún entre
commit ó abort
Si una transacción hace commit, sus hijas en provisional commit
pueden hacer commit, siempre que un ancestro no haya hecho abort
C.Ruz (PUC)
IIC2523
1/2013
91 / 115
Transacciones
¿Cómo obtener serializaciones?
Tres maneras de controlar concurrencia:
Locks
Control de concurrencia optimista
Ordenamiento de timestamps
C.Ruz (PUC)
IIC2523
1/2013
92 / 115
Transacciones
Locks
Locks
Locks a nivel de cada objeto accedido
Mayor granularidad de locks permite más transacciones concurrentes
Mayor atención a posibilidad de deadlocks
Ventaja
Posibilidad de obtener mayor concurrencia de transacciones
Desventaja
Mayor overhead para evitar deadlocks en la medida que se aumenta la
granularidad
C.Ruz (PUC)
IIC2523
1/2013
93 / 115
Transacciones
Control de concurrencia optimista
Supongamos que todo va a andar bien
No se hacen chequeos de conflicto durante la ejecución
Sólo al hacer commit se verifica la consistencia de los objetos
Si se detectan conflictos, se abortan las transacciones involucradas
Ventaja
Máximo paralelismo con mı́nimo overhead, cuando no hay conflictos
Desventaja
Transacciones son mucho más lentas cuando se producen conflictos
C.Ruz (PUC)
IIC2523
1/2013
94 / 115
Transacciones
El servidor guarda el timestamp del read y write más recientes para
cada operación sobre un objeto.
De acuerdo al timestamp, una nueva operación puede ser ejecutada
inmediatamente, delayed, ó rejected
Operaciones delayed hacen que la transacción espere.
Operaciones rejected hacen que la operación aborte.
Ventajas
No produce deadlocks.
Desventajas
Overhead puede ser importante al tener que analizar cada operación.
C.Ruz (PUC)
IIC2523
1/2013
95 / 115
Transacciones
Transacciones Distribuidas
Los objetos y, por lo tanto, las operaciones, se ejecutan en distintos nodos.
C.Ruz (PUC)
IIC2523
1/2013
96 / 115
Transacciones
Ejemplo: transacción bancaria anidada y distribuida
C.Ruz (PUC)
IIC2523
1/2013
97 / 115
Transacciones
Cada transacción distribuida utiliza un coordinador
Operación adicional: join(transID, refToParticipant)
Cada participante se hace conocer con el coordinador.
Coordinador usa esta información para organizar commit y abort
C.Ruz (PUC)
IIC2523
1/2013
98 / 115
Transacciones
Coordinador
La pregunta: ¿cómo se organizan los commits?
C.Ruz (PUC)
IIC2523
1/2013
99 / 115
Transacciones
Commit protocols
Objetivo: garantizar atomicidad al hacer commit en una transacción
distribuida
Approach simple: one-phase commit
Coordinador indica commit o abort a todos hasta que digan ACK.
Algunos procesos pueden haber hecho commit y otros abort
Si alguien dice abort, la transacción completa deberı́a hacer abort
Pero algún proceso ya podrı́a haber hecho commit
C.Ruz (PUC)
IIC2523
1/2013
100 / 115
Transacciones
Two-phase Commit
¡Usar dos etapas!
Etapa 1: los procesos votan por commit o abort
No pueden arrepentirse de votar commit
Pero pueden ser obligados a hacer abort
Procesos guardan estados antes de la modificación.
Etapa 2: la decisión final es transmitida
Si un proceso vota abort, se hace abort
Los procesos ejecutan el commit o el abort
C.Ruz (PUC)
IIC2523
1/2013
101 / 115
Transacciones
Two-phase Commit
Operaciones necesarias
C.Ruz (PUC)
IIC2523
1/2013
102 / 115
Transacciones
Two-phase Commit
Protocolo
C.Ruz (PUC)
IIC2523
1/2013
103 / 115
Contenidos
1
Estados Globales
2
3
Transacciones
4
C.Ruz (PUC)
IIC2523
1/2013
104 / 115
Tolerancia a Fallas
Permitir a un sistema continuar funcionando, o retomar su funcionamiento
ante eventos externos
Caı́das (bloqueos)
Falta de conectividad (unreachability)
Desafı́o
Reiniciar todo el sistema, o recuperar la ejecución desde un estado
establecido.
¿Desde qué estado?
C.Ruz (PUC)
IIC2523
1/2013
105 / 115
Tolerancia a Fallas
Checkpointing
Cada proceso guarda su estado a intervalos “regulares”.
Incluyendo los canales de comunicación
Al momento de recuperación, cada proceso se reinicia desde su último
checkpointing
Esto no garantiza que el estado global de recuperación sea consistente
Los procesos que hacen el estado inconsistente se reinician desde su
checkpoint anterior
Peor caso: se regresa al estado inicial (efecto dominó)
C.Ruz (PUC)
IIC2523
1/2013
106 / 115
Tolerancia a Fallas
Checkpointing coordinado
Proceso coordinador inicia algoritmo de snapshots
Se asegura que estados almacenados son consistentes
C.Ruz (PUC)
IIC2523
1/2013
107 / 115
Replicación
Dos o más procesos ejecutan la misma acción
Operación que modifica un estado
Actualización de datos
Usuario debe observar imagen única del sistema
Dos accesos consecutivos pueden ser a distintas réplicas, pero deben
proveer el mismo resultado.
C.Ruz (PUC)
IIC2523
1/2013
108 / 115
Modelos de Replicación
Secuencias de eventos
1 Request. Front-end (FE) envı́a requests a replica managers (RM)
2 Coordination. Antes de ejecutar, RMs necesitan acordar un orden.
FIFO. Si FE envı́a r y luego r 0 , los RM ejecutan r y después r 0
Causal. Si r → r 0 , los RM ejecutan r y después r 0
Total. Si un RM ejecutan r y después r 0 , todos ejecutan r y después r 0
3
4
5
Execution. Cada RM ejecuta la operación. Posiblemente de manera
tentativa usando espacios privados, o logs.
Agreement. RMs acuerdan el resultado de la ejecución.
Response. RMs responden al FE, y éste responde al cliente. Puede
haber algún post-proceso para enmascarar fallas.
C.Ruz (PUC)
IIC2523
1/2013
109 / 115
Técnicas de Replicación
Dos maneras de generar réplicas
Pasiva. Primay Backup
Activa
C.Ruz (PUC)
IIC2523
1/2013
110 / 115
Replicación Pasiva
Un replica manager primario (master) y muchos secundarios (slaves)
Operaciones son ejecutadas por el master y copiadas a los slaves
¿Si el master falla?
Se elige un nuevo master entre los slaves
Eventos
1
Request. FE envı́a request al replica manager master
2
Coordination. Toma la operación recibida en orden FIFO.
3
Execution. Master ejecuta la operación y almacena la respuesta.
4
Agreement. Si la operación es un update propaga el nuevo estado, la
respuesta, y el identificador de la operación a cada slave. Los slaves
envı́an un ACK.
5
Response. Master responde al FE.
C.Ruz (PUC)
IIC2523
1/2013
111 / 115
Operaciones son linealizables si el master funciona correctamente.
Master secuencializa las operaciones.
Si el master falla:
Slaves eligen nuevo master (elección)
Slaves acuerdan últimas operaciones efectuadas (consenso)
C.Ruz (PUC)
IIC2523
1/2013
112 / 115
# máximo de fallas
Si no hay procesos bizantinos, para soportar f fallas se necesitan
f + 1 managers
Ventaja: simple de implementar
Desventaja: overhead lineal en la cantidad de slaves
Master no declara la operación terminada hasta recibir ACKs de todos
los slaves.
C.Ruz (PUC)
IIC2523
1/2013
113 / 115
Replicación Activa
Los replica manager funcionan como máquinas de estado y son peers
FE envı́a operación a todos los RM.
Cada RM ejecuta la operación de manera independiente y responde.
Transparente a la falla de algún RM
FE puede recolectar respuestas, y detectar fallas bizantinas
Eventos
1 Request. FE envı́a request con identificar único a todos los RM
(multicast).
2 Coordination. Todos reciben request en el mismo orden.
3 Execution. Cada RM ejecuta la operación y obtiene una respuesta.
4 Agreement. No hay acuerdo entre RMs. Cada uno envı́a respuesta
independientemente
5 Response. FE puede manejar fallas por caı́da (enviando la primera
respuesta que recibe), o fallas bizantinas (coleccionando respuestas
C.Ruz (PUC)
IIC2523
1/2013
114 / 115
Replicación Activa
Orden secuencial depende del orden que puede alcanzar el multicast
Importante que todos vean el mismo orden.
C.Ruz (PUC)
IIC2523
1/2013
115 / 115

04 - Algoritmos Distribuidos - IIC2523

Transcripción

Documentos relacionados

www.zeno-watch.ch

El Grupo Festina triunfa de nuevo en Baselworld

solicitud de compensación económica