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