04 - Algoritmos Distribuidos - IIC2523
Transcripción
04 - Algoritmos Distribuidos - IIC2523
04 - Algoritmos Distribuidos IIC2523 - Sistemas Distribuidos Cristian Ruz – [email protected] Departamento de Ciencia de la Computación Pontificia Universidad Católica de Chile Semestre 1-2013 C.Ruz (PUC) IIC2523 1/2013 1 / 115 Contenidos 1 Estados Globales y Tiempo Relojes, eventos y estados Sincronización de Relojes Relojes y Vectores Lógicos Estados Globales 2 Exclusión Mutua y Consenso Exclusión Mutua Distribuida Elección y Consenso 3 Transacciones 4 Tolerancia a Fallas y Replicación C.Ruz (PUC) IIC2523 1/2013 2 / 115 Algoritmos Distribuidos Conceptos fundamentales algorı́tmicos Independiente de tecnologı́as particulares Modelo de ejecución particular: Se ejecutan en procesadores independientes Toman decisiones basados en información local No poseen toda la información del sistema No hay una fuente precisa de tiempo global C.Ruz (PUC) IIC2523 1/2013 3 / 115 Estados Globales y Tiempo Contenidos 1 Estados Globales y Tiempo Relojes, eventos y estados Sincronización de Relojes Relojes y Vectores Lógicos Estados Globales 2 Exclusión Mutua y Consenso Exclusión Mutua Distribuida Elección y Consenso 3 Transacciones 4 Tolerancia a Fallas y Replicación C.Ruz (PUC) IIC2523 1/2013 4 / 115 Estados Globales y Tiempo La importancia del tiempo Para muchas aplicaciones es importante conocer el tiempo en que se ejecutó alguna instrucción (o evento). Timestamps para: Consistencia Sincronización Prevención de duplicados Compilación automática (make) ... C.Ruz (PUC) IIC2523 1/2013 5 / 115 Estados Globales y Tiempo Necesitamos medir el tiempo Pero no es tan fácil medir el tiempo, ¿por qué? Teorı́a Especial de la Relatividad Observaciones de eventos son relativas Dos eventos simultá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 Estados Globales y Tiempo Pero estamos hablando de computadores . . . . . . que no viajan a la velocidad de la luz ¿Cómo generar timestamps precisos en nodos distintos? Para dos eventos e1 , e2 , ¿cuál ocurrió primero? ¿ocurrieron “simultáneamente”? ¡No hay un reloj global! Sin embargo,. . . los algoritmos funcionan . . . Dos problemas Sincronizar relojes usando paso de mensajes Observación del estado global de un sistema distribuido C.Ruz (PUC) IIC2523 1/2013 7 / 115 Estados Globales y Tiempo Relojes, eventos y estados Modelo Consideramos un sistema distribuido como una colecció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 Sólo se comunican por paso de mensajes: send y recv Cada proceso pi tiene un estado si que cambia durante la ejecución. Evento Ocurrencia de una acción individual send, recv u otra acción que cambie el estado del pi C.Ruz (PUC) IIC2523 1/2013 8 / 115 Estados Globales y Tiempo Relojes, eventos y estados Historia Los eventos dentro de pi poseen un orden total, definido por la relación →i Relació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 relación →i history (pi ) = hi = hei0 , ei1 , ei2 , . . .i C.Ruz (PUC) IIC2523 1/2013 9 / 115 Estados Globales y Tiempo Relojes, eventos y estados Relojes ¿Y có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 Estados Globales y Tiempo Relojes, eventos y estados Relojes Distorsión (skew) y desviación (drift) Pero los relojes no son perfectos. Para dos relojes distintos: Skew. Diferencia entre lecturas simultáneas de ambos relojes. Drift. Desviación o divergencia producto del ritmo de conteo. Algunos nú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 precisión”: 10−7 a 10−8 segundos por cada segundo real. Relojes atómicos: 10−13 C.Ruz (PUC) IIC2523 1/2013 11 / 115 Estados Globales y Tiempo Relojes, eventos y estados Relojes Tiempo Coordinado Universal: UTC Una solución: sincronización con fuentes externas “confiables” International Atomic Time (IAT): medido con relojes atómicos 1 segundo (desde 1967) 1 segundo se define como 9192631770 oscilaciones de la radiación emitida en la transición entre dos niveles hiperfinos del estado fundamental del isótopo 133 de un átomo de Cesio (133 Cs) a una temperatura de 0o K Antes de 1967: definido por rotación y traslación de la Tierra. UTC = Time Coordinated Universal Time = Temps Universel Coordonné Basado en IAT + leap seconds1 Emitido de señales terrestres y satelitales (incluyendo GPS time) Precisión ∼ 0.1 − −10 msec (tierra), ∼ 1µsec satelital 1 25 agregados desde 1972. El último en June 30, 2012 at 23:59:60 UTC C.Ruz (PUC) IIC2523 1/2013 12 / 115 Estados Globales y Tiempo Sincronización de Relojes Sincronizando Relojes Fı́sicos Dos estilos de sincronización: externa . . . e interna D > 0 es un cota de sincronización, y S es una fuente de tiempo UTC. Sincronizació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. Sincronizació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. Sincronización interna no implica necesariamente sincronización externa. (¿Por qué?) Si el sistema está sincronizado externamente hasta D, ¿qué se puede decir de la sincronización interna? C.Ruz (PUC) IIC2523 1/2013 13 / 115 Estados Globales y Tiempo Sincronización de Relojes Sincronizando Relojes Fı́sicos Noción de correctitud. Correctitud Reloj es correcto si su desviación está 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) Tambié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 Estados Globales y Tiempo Sincronización de Relojes Sincronizando Relojes Fı́sicos Problema de Sincronizació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 máximo será a lo más u Si pj establece su reloj en t + max, el desfase máximo será a lo má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 práctica es difı́cil establecer max, y se usa Ttrans = min + x, x ≥ 0 C.Ruz (PUC) IIC2523 1/2013 15 / 115 Estados Globales y Tiempo Sincronización de Relojes Sincronizando Relojes Fı́sicos Algoritmo de Cristian (1989) Método de sincronizació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 precisió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 recepción de mt : Tround p estima el tiempo real como t + Tround /2. C.Ruz (PUC) IIC2523 1/2013 16 / 115 Estados Globales y Tiempo Sincronización de Relojes Sincronizando Relojes Fı́sicos Algoritmo de Cristian (1989) ¿Precisión? t podrı́a corresponder a cualquier momento del rango h Intervalo de recepció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 recepción de tm : [t + min, t + Tround − min] Desviación: ±(Tround /2 − min) Desviación depende de min C.Ruz (PUC) IIC2523 1/2013 17 / 115 Estados Globales y Tiempo Sincronización de Relojes Sincronizando Relojes Fı́sicos Algoritmo de Cristian (1989) Debilidades: Servicio centralizado Alternativa: consultar un grupo de servidores sincronizados Congestión en la red incrementa el tiempo de propagación Estimar min usando consultas repetidas Servidor malicioso Múltiples servidores + votación C.Ruz (PUC) IIC2523 1/2013 18 / 115 Estados Globales y Tiempo Sincronización de Relojes Sincronizando Relojes Fı́sicos Algoritmo de Berkeley (Gusella & Zatti, 1989) Sincronizació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̄ Cálculo puede utilizar un umbral de tiempo de transmisión max y descartar algunos valores pM envı́a a cada pi su desviación respecto a t̄ 2 Elección de lı́deres a ver en sección 4.2 C.Ruz (PUC) IIC2523 1/2013 19 / 115 Estados Globales y Tiempo Sincronización de Relojes Sincronizando Relojes Fı́sicos Network Time Protocol (NTP), 1995 Cristian y Berkeley diseñ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 precisión conectados a fuentes directas (radio, atómicas) sincronizados de acuerdo a nivel 1 sincronizados de acuerdo a nivel 2, . . . Servidores pueden cambiar de estrato si pierden conectividad Tres modos de sincronización: Multicast. Transmisión directa de servidor a clientes (LAN). Supone bajo delay. Baja precisión. Procedure-call. Clientes consultan servidores (como algoritmo de Cristian). Mayor precisión. Symmetric. Intercambios entre servidores del mismo estrato. C.Ruz (PUC) IIC2523 1/2013 20 / 115 Estados Globales y Tiempo Sincronización de Relojes Sincronizando Relojes Fı́sicos Network Time Protocol (NTP), 1995 C.Ruz (PUC) IIC2523 1/2013 21 / 115 Estados Globales y Tiempo Sincronización de Relojes Sincronizando Relojes Fı́sicos Network Time Protocol (NTP), 1995 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 más recientes C.Ruz (PUC) IIC2523 1/2013 22 / 115 Estados Globales y Tiempo Relojes y Vectores Lógicos Relaciones causales Lamport, 1978 Precisión de relojes fı́sicos tiene un lı́mite Sincronización perfecta es imposible en un sistema distribuido Pero dentro de un mismo proceso sı́ hay un orden absoluto Usar causalidad para establecer órdenes entre distintos procesos Dos observaciones importantes: Dos eventos e1 y e2 que ocurren en pi está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 relación ocurre antes entre eventos de distintos procesos C.Ruz (PUC) IIC2523 1/2013 23 / 115 Estados Globales y Tiempo Relojes y Vectores Lógicos Relación ocurre-antes (happens-before) Lamport, 1978 A.K.A. ordenamiento causal, u ordenamiento potencialmente causal Relació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 Estados Globales y Tiempo Relojes y Vectores Lógicos Relación ocurre-antes (happens-before) Lamport, 1978 ¿Qué 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 Estados Globales y Tiempo Relojes y Vectores Lógicos Relojes Lógicos Lamport, 1978 Un reloj lógico es un contador monótono creciente Cada proceso pi mantiene su propio reloj lógico Li Sin relació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 ocurrió C.Ruz (PUC) IIC2523 1/2013 26 / 115 Estados Globales y Tiempo Relojes y Vectores Lógicos Relojes Lógicos Lamport, 1978 Relojes lógicos se actualizan para capturar la relación ocurre-antes Actualización de Relojes Ló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 Estados Globales y Tiempo Relojes y Vectores Lógicos Relojes Lógicos Lamport, 1978 C.Ruz (PUC) IIC2523 1/2013 28 / 115 Estados Globales y Tiempo Relojes y Vectores Lógicos Relojes Lógicos Lamport, 1978 C.Ruz (PUC) IIC2523 1/2013 29 / 115 Estados Globales y Tiempo Relojes y Vectores Lógicos Orden total con relojes ló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? Solució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 Estados Globales y Tiempo Relojes y Vectores Lógicos 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 Actualización de Relojes Ló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 Estados Globales y Tiempo Relojes y Vectores Lógicos Relojes Vectoriales C.Ruz (PUC) IIC2523 1/2013 32 / 115 Estados Globales y Tiempo Relojes y Vectores Lógicos Relojes Vectoriales Mattern (1989), Fidge (1991) ¿Hay algún significado en estos valores? Vi [i], número de eventos marcados por pi Vi [j], j 6= i, número de eventos marcados en j que podrı́an haber afectado pj (potencialmente relacionados con pj ) ¿Có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 Estados Globales y Tiempo Relojes y Vectores Lógicos Relojes Vectoriales Mattern (1989), Fidge (1991) Debilidades: Almacenamiento y envı́o O(N) Charron-Bost (1991) demuestra que para determinar la relación ocurre-antes usando timestamps, es necesario utilizar las N dimensiones Raynal & Singhal (1996) indicando maneras de enviar menos informació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 y Tiempo Estados Globales Propiedades globales Problema: determinar algunas propiedades en sistemas distribuidos ¿Hay referencias externas a un objeto local? Recolección de basura distribuida Contador local es 0, pero puede haber referencias “en camino”. ¿Está el sistema en un estado de bloqueo mutuo? Detección de deadlock distribuido ¿Ha terminado el algoritmo distribuido? No es un halting problem distribuido Detección de terminació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 y Tiempo Estados Globales Propiedades globales C.Ruz (PUC) IIC2523 1/2013 36 / 115 Estados Globales y Tiempo Estados Globales ¿Có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-é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 y Tiempo Estados Globales ¿Cómo coleccionar un estado global? Definiciones Fronteras he10 , e20 i, he12 , e22 i Corte inconsistente: incluye recepción de m pero no su envı́o. Corte consistente: incluye envı́o y recepción, o bien sólo envı́o. Corte consistente C : ∀e ∈ C , f → e ⇒ f ∈ C Por cada evento, también están los que ocurrieron antes que él. Un corte consistente define un estado global consistente La ejecució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 Tiempo Estados Globales ¿Cómo coleccionar un estado global? Y más definiciones Run: Orden total de eventos, que es consistente con las historias locales hi Linearización ó Run consistente: Orden de eventos de una historia global que es consistente con la relación ocurre antes. Una linearización también es un run. No todos los runs pasan por estado globales consistentes. Una linearización solo pasa por estados globales consistentes. C.Ruz (PUC) IIC2523 1/2013 39 / 115 Estados Globales y Tiempo Estados Globales ¿Cómo coleccionar un estado global? Algoritmo de snapshot: Chandy y Lamport (1985) Permite observar estados globales consistentes Captura estados de procesos y de canales de comunicació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 algún momento Canales unidireccionales y entrega FIFO El grafo de procesos y canales está fuertemente conectado El algoritmo puede ser iniciado por cualquier proceso Los procesos pueden continuar su ejecución concurrentemente con el algoritmo de snapshot C.Ruz (PUC) IIC2523 1/2013 40 / 115 Estados Globales y Tiempo 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 despué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 aú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 y Tiempo Estados Globales Algoritmo de Chandy y Lamport (1985) Mensajes marker Recepció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 guardó su estado La primera vez obliga a un proceso a guardar su estado, y guarda los mensajes en cada canal Desde la segunda recepción de un marker, guarda los mensajes recibidos en cada canal C.Ruz (PUC) IIC2523 1/2013 42 / 115 Estados Globales y Tiempo Estados Globales Algoritmo de Chandy y Lamport (1985) 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 través de c, antes de enviar cualquier otro mensaje a través de c Cualquier proceso pi puede iniciar el algoritmo. pi comienza como si hubiese recibido un marker a través de un canal inexistente Puede haber más de una instancia del algoritmo ejecutándose, iniciada por distintos procesos Solo se necesita ser capaz de distinguir los markers. C.Ruz (PUC) IIC2523 1/2013 43 / 115 Estados Globales y Tiempo Estados Globales Algoritmo de Chandy y Lamport (1985) Ejemplo C.Ruz (PUC) IIC2523 1/2013 44 / 115 Exclusión Mutua y Consenso Contenidos 1 Estados Globales y Tiempo Relojes, eventos y estados Sincronización de Relojes Relojes y Vectores Lógicos Estados Globales 2 Exclusión Mutua y Consenso Exclusión Mutua Distribuida Elección y Consenso 3 Transacciones 4 Tolerancia a Fallas y Replicación C.Ruz (PUC) IIC2523 1/2013 45 / 115 Exclusión Mutua y Consenso Dos problemas Exclusión Mutua Distribuida Coordinación de procesos para compartir recursos. Evitar race conditions. Selección de procesos. Consenso Alcance de acuerdo en presencia de fallas o procesos “maliciosos” (bizantinos). C.Ruz (PUC) IIC2523 1/2013 46 / 115 Exclusión Mutua y Consenso Exclusión Mutua Distribuida Exclusión Mutua Distribuida Solución centralizada Un proceso funciona como lock master, y entrega locks de acceso a secciones crı́ticas. Factible hasta cierta cantidad de procesos. Solución distribuida No siempre es posible designar un lock master Ejemplo: Redes ethernet ó wifi ’ad-hoc’: sólo un nodo debe transmitir a través del medio Tres algoritmos Ring-based Ricart-Agrawala (1981) Maekawa (1985) C.Ruz (PUC) IIC2523 1/2013 47 / 115 Exclusión Mutua y Consenso Exclusión Mutua Distribuida 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 exclusión mutua ME1. Safety : A lo más un proceso se encuentra en la sección crı́tica simultáneamente. ME2. Liveness : Todo proceso que quiere entrar la sección crı́tica lo consigue en algún momento. No hay deadlock ni starvation ME3. Orden → . Una solicitud de entrada a sección crı́tica a es atendida antes que una solicitud b si es que a → b. C.Ruz (PUC) IIC2523 1/2013 48 / 115 Exclusión Mutua y Consenso Exclusión Mutua Distribuida 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 sección crı́tica debe devolver el token Mientras alguien tenga el token, procesos son encolados C.Ruz (PUC) IIC2523 1/2013 49 / 115 Exclusión Mutua y Consenso Exclusión Mutua Distribuida 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 Exclusión Mutua y Consenso Exclusión Mutua Distribuida Algoritmo Ring-based Procesos organizados en un anillo lógico pi só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 Exclusión Mutua y Consenso Exclusión Mutua Distribuida Algoritmo Ring-based #mensajes: Entre 0 y N, má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 Exclusión Mutua y Consenso Exclusión Mutua Distribuida Algoritmo de Ricart y Agrawala (1981) Procesos hacen multicast a los demás Cada proceso pi mantiene un reloj lógico Li Mensajes de entrada incluyen hLi , pi i Procesos poseen un estado: RELEASED. Se encuentra fuera de sección crı́tica WANTED. Desea entrar a sección crı́tica HELD. Se encuentra dentro de sección crı́tica C.Ruz (PUC) IIC2523 1/2013 53 / 115 Exclusión Mutua y Consenso Exclusión Mutua Distribuida Algoritmo de Ricart y Agrawala (1981) C.Ruz (PUC) IIC2523 1/2013 54 / 115 Exclusión Mutua y Consenso Exclusión Mutua Distribuida Algoritmo de Ricart y Agrawala (1981) C.Ruz (PUC) IIC2523 1/2013 55 / 115 Exclusión Mutua y Consenso Exclusión Mutua Distribuida Algoritmo de Ricart y Agrawala (1981) Inicialmente, ∀i, Spi = RELEASED Cuando pi quiere entrar a la secció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 sección crı́tica Spi = RELEASED Responder a todas las solicitudes encoladas C.Ruz (PUC) IIC2523 1/2013 56 / 115 Exclusión Mutua y Consenso Exclusión Mutua Distribuida Algoritmo de Ricart y Agrawala (1981) #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 Exclusión Mutua y Consenso Exclusión Mutua Distribuida Algoritmo de Maekawa (1985) Observación: se debe pedir acceso a todos Es posible pedir acceso sólo a un subconjunto Siempre que los subconjuntos se traslapen Proceso se convierten en candidatos que recolectan votos Procesos en la intersecció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 √ Solución óptima se obtiene con K ∼ N, y M = K C.Ruz (PUC) IIC2523 1/2013 58 / 115 Exclusión Mutua y Consenso Exclusión Mutua Distribuida Algoritmo de Maekawa (1985) C.Ruz (PUC) IIC2523 1/2013 59 / 115 Exclusión Mutua y Consenso Exclusión Mutua Distribuida Algoritmo de Maekawa (1985) Inicialmente: ∀i, Spi = RELEASED, voted i = FALSE Cuando pi quiere entrar a la secció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 sección crı́tica Spi = RELEASED Envı́a mensaje release a todos los miembros de Vi C.Ruz (PUC) IIC2523 1/2013 60 / 115 Exclusión Mutua y Consenso Exclusión Mutua Distribuida Algoritmo de Maekawa (1985) 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 (¿cómo?) Puede solucionarse introduciendo prioridades, al costo de aumentar los √ mensajes a 5 N C.Ruz (PUC) IIC2523 1/2013 61 / 115 Exclusión Mutua y Consenso Elección y Consenso Algoritmos de Elección ¿Para qué? 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 desaparición del master puede iniciar la elección Podrı́a haber N elecciones simultá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 Exclusión Mutua y Consenso Elección y Consenso Algoritmos de Elección Requisitos E1. Safety Un proceso participante pi tiene elected i == null, ó elected i == P, donde P es el proceso con mayor id E2. Liveness Todos los procesos pi participan de la elección y llegan, en algún momento a elected i 6= null. C.Ruz (PUC) IIC2523 1/2013 63 / 115 Exclusión Mutua y Consenso Elección y Consenso Algoritmo Ring-based de Chang y Roberts (1979) Inicialmente, ∀pi , participant i = FALSE Cuando pi inicia una elecció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 Exclusión Mutua y Consenso Elección y Consenso Algoritmo Ring-based de Chang y Roberts (1979) 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 Exclusión Mutua y Consenso Elección y Consenso Algoritmo Ring-based de Chang y Roberts (1979) #mensajes: Peor caso: el lı́der es el vecino anterior a quien inicio la elecció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 Exclusión Mutua y Consenso Elección y Consenso Algoritmo del Matón (Bully), Garcia-Molina (1982) Tolerante a caı́das de procesos durante la elección pi conoce a los que tienen mayor id pi puede comunicarse con cualquier proceso Tres tipos de mensajes Election. Para iniciar una elección. Answer. Respuesta un mensaje election. Coordinator. Mensaje para anunciar al lı́der. C.Ruz (PUC) IIC2523 1/2013 67 / 115 Exclusión Mutua y Consenso Elección y Consenso Algoritmo del Matón (Bully), Garcia-Molina (1982) Algoritmo se inicia cuando pi detecta caı́da (timeout) del lı́der. pi inicia la elección enviando un mensaje Election a todos los que tienen pid > pi , y espera algún mensaje Answer. Si ninguno de ellos responde, entonces pi supone que él tiene mayor id, y envı́a un mensaje Coordinator auto-anunciándose como nuevo lider Si pi recibe un Answer de lo que tiene pid > pi , entonces espera un tiempo T para que é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 elección. C.Ruz (PUC) IIC2523 1/2013 68 / 115 Exclusión Mutua y Consenso Elección y Consenso Algoritmo del Matón (Bully), Garcia-Molina (1982) C.Ruz (PUC) IIC2523 1/2013 69 / 115 Exclusión Mutua y Consenso Elección y Consenso Algoritmo del Matón (Bully), Garcia-Molina (1982) #mensajes: Mejor caso: el que tiene el segundo id más grande es el ú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 elección: N − 1 elecciones O(N 2 ) mensajes Ventaja Tolerancia a la falla de algún proceso durante la elección C.Ruz (PUC) IIC2523 1/2013 70 / 115 Exclusión Mutua y Consenso Elección y Consenso 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 decisió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 Exclusión Mutua y Consenso Elección y Consenso Consenso Ejemplo: N procesos Cada proceso pi elige un valor vi y lo envı́a a los demás. Cuando cada proceso pi ha coleccionado los N valores, calcula el que más se ha repetido, o algún valor null si no hay ninguna mayorı́a. Todos terminan en estado decided con di = majority (v1 , v2 , . . . , vN ), o bien di = null. ¿Qué ocurre ante una caı́da? El algoritmo podrı́a no terminar. ¿Qué pasa si un proceso ”miente”? Se puede llegar a consenso en un valor incorrecto C.Ruz (PUC) IIC2523 1/2013 72 / 115 Exclusión Mutua y Consenso Elección y Consenso Consenso Problema de los Generales Bizantinos (Lamport, Shostak, Pease, 1982) Tres o más generales deben decider entre atacar ó retirarse. Pero uno o má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 Exclusión Mutua y Consenso Elección y Consenso Consenso Consenso en sistemas sı́ncronos N procesos, donde a lo más f pueden caerse durante la ejecución. Se ejecutan f + 1 iteraciones Cada procesos obtiene los valores de los demás En cada iteración, los procesos correctos reenvı́an sus valores entre ellos. En el peor caso, un proceso se cae en cada iteración Se necesita una iteración má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 Exclusión Mutua y Consenso Elección y Consenso Consenso Consenso en sistemas sı́ncronos C.Ruz (PUC) IIC2523 1/2013 75 / 115 Exclusión Mutua y Consenso Elección y Consenso Consenso Generales bizantinos en sistemas sı́ncronos N procesos, donde a lo más f pueden tener fallas arbitrarias. Caso de 3 procesos Imposible con 3 procesos C.Ruz (PUC) IIC2523 1/2013 76 / 115 Exclusión Mutua y Consenso Elección y Consenso Consenso Generales bizantinos en sistemas sı́ncronos Caso de N=4 procesos, y f=1 bizantino Posible con N ≥ 3f + 1 C.Ruz (PUC) IIC2523 1/2013 77 / 115 Exclusión Mutua y Consenso Elección y Consenso Consenso Generales bizantinos en sistemas sı́ncronos #mensajes No es posible asegurar la recepción de todos los mensajes en menos de f iteraciones. Se debe ejecutar al menos f + 1 iteraciones En cada iteració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 número de mensajes a O(N 2 ) (Dolev & Strong, 1983) C.Ruz (PUC) IIC2523 1/2013 78 / 115 Exclusión Mutua y Consenso Elección y Consenso Consenso Generales bizantinos en sistemas sı́ncronos Problema equivalente Consistencia interactiva: obtener consenso en un vector CI i de valores para cada proceso. Suponiendo que hay una solución para Generales Bizantinos (BG) Ejecutar la solución de BG N veces, en la cual cada procesos pi va tomando el rol de comandante. BG i (j, v ) es una solució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 Exclusión Mutua y Consenso Elección y Consenso Consenso Generales bizantinos en sistemas ası́ncronos Fischer et al.,1985: imposible garantizar consenso en un sistema ası́ncrono, aún con una ú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 demá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 práctica, sı́ncrono Consenso bajo aleatoriedad: introducir modificaciones aleatorias en algunos mensajes Más que una solución para obtener consenso en el caso ası́ncrono, es una manera evitar el éxito de un adversario bizantino. C.Ruz (PUC) IIC2523 1/2013 80 / 115 Transacciones Contenidos 1 Estados Globales y Tiempo Relojes, eventos y estados Sincronización de Relojes Relojes y Vectores Lógicos Estados Globales 2 Exclusión Mutua y Consenso Exclusión Mutua Distribuida Elección y Consenso 3 Transacciones 4 Tolerancia a Fallas y Replicación 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 bá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 Serializació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 Serialización correcta C.Ruz (PUC) IIC2523 1/2013 88 / 115 Transacciones Serialización y operaciones conflictivas Equivalencia Serial La entremezcla interleaving de operaciones de dos o más transacciones es serialmente equivalente si su efecto es el mismo de haber ejecutado cada transacción completa en algú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 cuáles son las operaciones conflictivas? read vs write write vs write C.Ruz (PUC) IIC2523 1/2013 89 / 115 Transacciones Serializació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 ejecución T , U, ni a la ejecución U, T C.Ruz (PUC) IIC2523 1/2013 90 / 115 Transacciones Transacciones anidadas Subtransacciones pueden hacer commit o abort de manera independiente Una transacción hace commit ó abort solo si sus hijas han terminado. Una subtransacción hace provisional commit ó abort Cuando una transacción hace abort, todas sus hijas hacen abort Si una subtransacción hace abort, el padre puede decir aún entre commit ó abort Si una transacció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 ¿Có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 más transacciones concurrentes Mayor atenció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 ejecución Sólo al hacer commit se verifica la consistencia de los objetos Si se detectan conflictos, se abortan las transacciones involucradas Ventaja Máximo paralelismo con mı́nimo overhead, cuando no hay conflictos Desventaja Transacciones son mucho más lentas cuando se producen conflictos C.Ruz (PUC) IIC2523 1/2013 94 / 115 Transacciones Ordenamiento de timestamps Ordenamiento de timestamps El servidor guarda el timestamp del read y write más recientes para cada operación sobre un objeto. De acuerdo al timestamp, una nueva operación puede ser ejecutada inmediatamente, delayed, ó rejected Operaciones delayed hacen que la transacción espere. Operaciones rejected hacen que la operación aborte. Ventajas No produce deadlocks. Desventajas Overhead puede ser importante al tener que analizar cada operació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 Transacciones Distribuidas Ejemplo: transacción bancaria anidada y distribuida C.Ruz (PUC) IIC2523 1/2013 97 / 115 Transacciones Transacciones Distribuidas Cada transacción distribuida utiliza un coordinador Operación adicional: join(transID, refToParticipant) Cada participante se hace conocer con el coordinador. Coordinador usa esta información para organizar commit y abort C.Ruz (PUC) IIC2523 1/2013 98 / 115 Transacciones Transacciones Distribuidas Coordinador La pregunta: ¿cómo se organizan los commits? C.Ruz (PUC) IIC2523 1/2013 99 / 115 Transacciones Commit protocols Objetivo: garantizar atomicidad al hacer commit en una transacció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 transacción completa deberı́a hacer abort Pero algú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 modificación. Etapa 2: la decisió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 Tolerancia a Fallas y Replicación Contenidos 1 Estados Globales y Tiempo Relojes, eventos y estados Sincronización de Relojes Relojes y Vectores Lógicos Estados Globales 2 Exclusión Mutua y Consenso Exclusión Mutua Distribuida Elección y Consenso 3 Transacciones 4 Tolerancia a Fallas y Replicación C.Ruz (PUC) IIC2523 1/2013 104 / 115 Tolerancia a Fallas y Replicación 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 ejecución desde un estado establecido. ¿Desde qué estado? C.Ruz (PUC) IIC2523 1/2013 105 / 115 Tolerancia a Fallas y Replicación Tolerancia a Fallas Checkpointing Cada proceso guarda su estado a intervalos “regulares”. Incluyendo los canales de comunicación Al momento de recuperación, cada proceso se reinicia desde su último checkpointing Esto no garantiza que el estado global de recuperación sea consistente Los procesos que hacen el estado inconsistente se reinician desde su checkpoint anterior Peor caso: se regresa al estado inicial (efecto dominó) C.Ruz (PUC) IIC2523 1/2013 106 / 115 Tolerancia a Fallas y Replicación 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 Tolerancia a Fallas y Replicación Replicación Dos o más procesos ejecutan la misma acción Operación que modifica un estado Actualización de datos Usuario debe observar imagen única del sistema Dos accesos consecutivos pueden ser a distintas réplicas, pero deben proveer el mismo resultado. C.Ruz (PUC) IIC2523 1/2013 108 / 115 Tolerancia a Fallas y Replicación Modelos de Replicació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 después r 0 Causal. Si r → r 0 , los RM ejecutan r y después r 0 Total. Si un RM ejecutan r y después r 0 , todos ejecutan r y después r 0 3 4 5 Execution. Cada RM ejecuta la operación. Posiblemente de manera tentativa usando espacios privados, o logs. Agreement. RMs acuerdan el resultado de la ejecución. Response. RMs responden al FE, y éste responde al cliente. Puede haber algún post-proceso para enmascarar fallas. C.Ruz (PUC) IIC2523 1/2013 109 / 115 Tolerancia a Fallas y Replicación Técnicas de Replicación Dos maneras de generar réplicas Pasiva. Primay Backup Activa C.Ruz (PUC) IIC2523 1/2013 110 / 115 Tolerancia a Fallas y Replicación Replicació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 operación recibida en orden FIFO. 3 Execution. Master ejecuta la operación y almacena la respuesta. 4 Agreement. Si la operación es un update propaga el nuevo estado, la respuesta, y el identificador de la operación a cada slave. Los slaves envı́an un ACK. 5 Response. Master responde al FE. C.Ruz (PUC) IIC2523 1/2013 111 / 115 Tolerancia a Fallas y Replicación Replicación Pasiva Operaciones son linealizables si el master funciona correctamente. Master secuencializa las operaciones. Si el master falla: Slaves eligen nuevo master (elección) Slaves acuerdan últimas operaciones efectuadas (consenso) C.Ruz (PUC) IIC2523 1/2013 112 / 115 Tolerancia a Fallas y Replicación Replicación Pasiva # má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 operación terminada hasta recibir ACKs de todos los slaves. C.Ruz (PUC) IIC2523 1/2013 113 / 115 Tolerancia a Fallas y Replicación Replicación Activa Los replica manager funcionan como máquinas de estado y son peers FE envı́a operación a todos los RM. Cada RM ejecuta la operación de manera independiente y responde. Transparente a la falla de algún RM FE puede recolectar respuestas, y detectar fallas bizantinas Eventos 1 Request. FE envı́a request con identificar único a todos los RM (multicast). 2 Coordination. Todos reciben request en el mismo orden. 3 Execution. Cada RM ejecuta la operació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 Tolerancia a Fallas y Replicación Replicació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