Comunicación en Grupos

Bibliografía Sistemas Operativos Distribuidos A. S. Tanenbaum, Prentice Hall, 1995 Distributed Systems Sape Mullender ,Editor. Addison Wesley –ACM Press 1994 Capítulos 11,12 y 13 Sistemas Distribuidos. Conceptos y Diseño G. Coulouris, J. Dollimore, T. Kindberg, Addison Wesley, 2001

Grupo o Proceso ? Gossip Process Group Collouris et al “ Our methodology is based on the PROCESS GROUP paradigm that has been suitably to partitionable systems “ BabaoGlu et. al Process Group , ISIS Birman 93

Introducción Comunicación en Grupos ( Group Communication) Algunas veces necesitamos que múltiples procesos se comuniquen entre ellos . ( Por ej. Un grupo de file servers cooperando para ofrecer un único servicio de archivos tolerante a fallas ) Comunicación en Grupos ( Group Communication) Colección de Procesos que actúan juntos en un cierto sistema o alguna forma determinada por el usuario. El propósito de la introducción de este paradigma es permitir a los procesos tratar con una colección de procesos como una única abstracción . Esto es , un proceso puede enviar un mensaje a un grupo de servidores sin tener que saber cuantos son y donde están .

Comunicación en grupo La comunicación es entre un grupo de procesos Cuando un emisor envía el mensaje lo reciben todos los miembros de un grupo Los grupos se entienden como dinámicos, se pueden crear y destruir grupos. Un proceso puede ser miembro de varios grupos, se puede unir a uno y dejar otro Algunas redes permiten diferentes tipos de broadcasting, lo que facilita la implementación de comunicación en grupo

Comunicación a nivel de Red Multicasting Broadcasting Unicasting

Comunicación en grupo Los grupos pueden ser: abiertos: no-miembros pueden enviar al grupo cerrados: solo los miembros pueden enviar al grupo Los miembros del grupo pueden ser iguales ( peers groups) , o bien existe un miembro coordinador o líder ( jerarquicos ) De existir, los envíos se hacen al coordinador, que decide a qué miembro reenviar Atomicidad: cuando se envía un mensaje a un grupo, llega a todos los miembros o no llega a ninguno La atomicidad es una propiedad deseable

Membresía (Group Membership) Servidor de Grupo ; Mantiene una BD centralizada de los grupos y miembros. Administración Distribuida: Envió mensaje “Hello” para unirme al grupo ( Grupo Abierto) Envió “Bye” para dejar el grupo Si un miembro falla , en realidad es como dejar al Grupo , no existe un mensaje de “Bye” . Los demás miembros deben descubrir experimentalmente . La entrada y salida a un grupo debe sincronizarse con el envió de mensajes : - Cuando lo deja no mas mensajes - Cuando se une debe recibir todos los mensajes Si fallan tantos procesos que no podemos reconstruir el Grupo , necesitamos un protocolo a tales efectos

Direccionamiento al Grupo Group Addressing Para poder enviar un mensaje a un grupo , debo poder direccionarlo . Concepto de “Direccion_Grupo” Multicasting Broadcasting Unicasting: (point-to-point message ) Predicate addressing

Comunicación en grupo ¿cómo asegurar la atomicidad ( Atomic Broadcast )? La única forma de garantizar que cada miembro reciba el mensaje es pedirle que devuelva un reconocimiento al recibirlo pero ¿y si aun así falla algun host? Una solución [Birman89]: El emisor envía un mensaje a todos los miembros. Se setean timers y se reenvía el mensaje en los casos necesarios Cuando un miembro recibe el mensaje, si lo ha RX ya lo descarta. Si no, lo envía a todos los miembros del grupo (usando también Timers y retransmisiones, RTX). En un cierto T todos los Pi tendran Mi

Ordenamiento de Mensajes Otra propiedad deseable es la del ordenamiento de mensajes Supongamos 5 miembros. Los miembros P0,P1,P3 y P4 pertenecen a un mismo grupo A la misma vez, los miembros P0 y P4 desean enviar un mensaje (m) al grupo. Podrían enviarlos en este orden: 1 3 1 2 3 4 4 2 5

Ordenamiento de Mensajes (1) ¿cómo reciben los mensajes los miembros 1 y 3? P1 recibe los mensajes en este orden: mensaje de 0 mensaje de 4 P3 recibe los mensajes en este orden: No se cumple el ordenamiento de mensajes! Si P0 y P4 intentan actualizar el mismo item los miembros 1 y 3 terminan con distintos valores .

Ordenamiento de Mensajes (2) Se debe tener una semántica bien definida con respecto al orden de entrega de los Mi “ La mejor garantía es la entrega inmediata de todos los Mi en orden en que fueron enviados “ Un patrón de envió Global Time Ordering . El ordenamiento no es siempre fácil de implementar Tiempo Absoluto …. , variantes moderadas : Consistent Time Ordering . Si Ma y Mb llegan cercanos en t el sistema elige a uno como el Primero , si no lo era , nadie lo sabe .. El comportamiento no debería depender de el …. “Se garantiza que llegan en el mismo orden a todo el G, pero podría no ser con el que fueron enviados “ Existen otros ordenamientos mas débiles

Grupos Solapados Aunque se cumpla el ordenamiento de mensajes hay situaciones problemáticas Supongamos dos grupos solapados ( G1 y G2). A y D quieren enviar a la vez un mensaje a sus compañeros de grupo B y C reciben los mensajes en orden contrario B G2 1 G1 A D 3 C 2

Implementaciones ISIS toolkit: es un software que corre sobre Unix y brinda un entorno de multicast ordenado para entregar los requerimientos a los procesos Gossip: entrega los mensajes no ordenados, basándose en la propagación de updates entre procesos

Comunicación en Grupo en ISIS La idea fundamental es la Sincronía y la primitivas fundamentales son distintas formas de TX atómica Sistema Sincrónico es aquel en el que los eventos ocurren estrictamente en forma secuencial, donde cada evento tarda esencialmente un tiempo nulo en llevarse a cabo . En realidad son imposibles de construir Sistemas vagamente sincrónicos (loose synchrony) Los eventos tardan un tiempo finito Pero aparecen en el mismo orden para todos los Pi Todos los procesos reciben los mensajes en el mismo orden

Comunicación en Grupo en ISIS (1) Para ciertas aplicaciones se puede usar una semántica mas débil Sistema Virtualmente Sincrónico (virtual synchrony) En un DS dos eventos están relacionados de manera causal , si la naturaleza o comportamiento de un mensaje Si+1 esta influenciado por Si Eventos Concurrentes – Dos eventos no relacionados Sincronía Virtual : si dos mensajes están relacionados de manera causal , todos los procesos deben recibir en el mismo orden. Si son concurrentes, no se necesita garantizar orden , el sistema es libre de entregarlos con un orden distinto a los procesos si le es mas fácil

Primitivas de Comunicación Primitivas Broadcast ABCAST - vagamente sincrónica, básicamente un protocolo two-phase commit para TX de datos a los miembros del grupo GBCAST – igual que ABCAST pero para el manejo de la membresía CBCAST – comunicación virtualmente sincrónica Primitiva ABCAST Protocolo de compromiso de dos fases. Sea un Pi asigna una marca de tiempo ( # secuencial) a mi y se envía a todos los miembros de G . Cada uno elige elegía marca te tiempo mayor que cualquiera otra marca TX o RX , y lo envían a Pi. Al RX todos los mensajes elige el que tiene mayor marca de tiempo y envía un “commit” a todos los miembros que lo contuviera de nuevo. Los mensajes comprometidos se entregan a la aplicación según el orden de los timestamps

Estado de los Vectores en los otros nodos Primitiva CBCAST Condiciones para aceptar un Mensaje Vector en un Mensaje enviado por Po 1) Vj = Lj + 1 2) Vi <= Li para todo i <> j Estado de los Vectores en los otros nodos 4 6 8 2 1 5 1 3 7 8 2 5 2 3 5 8 1 3 7 8 2 1 5 4 2 6 8 1 5 5 3 7 8 1 Aceptado Delay Aceptado Delay Aceptado

Sincronización en DS

Introducción En un sistema con un procesador, la sincronización entre procesos usa herramientas como semáforos, monitores, etc. Esas facilidades suponen de manera implícita la existencia de memoria compartida En los DS no contamos con esa memoria compartida, se buscaron otras técnicas El simple hecho de determinar si el evento A ocurrió antes que el evento B requiere de un cuidadoso análisis .

Sincronización de relojes En un sistema centralizado, el tiempo no tiene ambigüedades Si el proceso A pide la hora, y un poco después el proceso B también la pide, el valor obtenido por B es siempre mayor o igual que el obtenido por A En un DS no es tan sencillo. ¿qué implica el carecer de un reloj global?

Sincronización de relojes Pensemos en el programa make en un entorno distribuido de dos máquinas La sincronización de relojes es muy importante! 2144 2145 2146 2147 máquina que ejecuta el compilador tiempo del reloj local output.o creado 2142 2143 2144 2145 máquina que ejecuta el editor tiempo del reloj local output.c creado

Sincronización de relojes ¿se pueden sincronizar los relojes en un sistema distribuido? Lamport demostró (1978) que sí: lo que importa no es una sincronización del tiempo absoluto, sino que el orden de los eventos sea el mismo en todas las máquinas En el ejemplo del make lo que importa no es la hora en que se crean output.o y ouput.c, sino el orden en que fueron creados Por otro lado, si dos procesos no interactuan, no es necesario que sus relojes estén sincronizados

Sincronización de relojes Tipos de relojes: relojes lógicos: las máquinas tienen el mismo valor de reloj, aunque marquen una hora distinta de la real relojes físicos: las máquinas tienen el mismo valor de reloj, y éste no debe desvíarse de la hora real más alla de cierta magnitud

Algoritmo de Lamport Lamport definió la relación “ocurre antes de” La expresión ab se lee “a ocurre antes de b” e indica que todos los procesos coinciden en que primero ocurre a y después b se cumple: Si a y b son dos eventos en el mismo proceso y a ocurre antes que b, entonces ab es verdadero Si a es el evento del envío de un mensaje por un proceso y b es el evento de la recepción del mensaje por otro proceso, entonces ab es verdadero “ocurre antes de” es una relacion transitiva : Si ab y bc ac

Sincronización de relojes lógicos ¿de qué forma podemos sincronizar relojes lógicos? Necesitamos una forma de asociar a cada evento a un valor de tiempo C(a) en el que todos los procesos estén de acuerdo Los valores de tiempo deben tener la propiedad de que si ab entonces C(a)<C(b) El tiempo de reloj C siempre debe ir hacia delante, nunca puede ser decreciente

Sincronización de relojes lógicos tres procesos, cada uno con su propio reloj Los relojes a distintas velocidades Con los mensajes C y D no se cumplen las reglas anteriores Po P1 P2 6 12 18 24 30 36 42 48 54 60 8 16 24 32 40 48 56 64 72 80 10 20 30 40 50 60 70 80 90 100 A B C D

Sincronización de relojes lógicos Solución propuesta por Lamport: puesto que C sale en 60 debe llegar en 61 o con un t posterior, ... Con una adicion este algoritmo cumple las necesidades para t global Po P1 P2 6 12 18 24 30 36 42 48 70 76 8 16 24 32 40 48 61 69 77 85 10 20 30 40 50 60 70 80 90 100 A B C D

Sincronización de relojes lógicos En ciertas situaciones existe un requisito adicional: dos eventos no ocurren exactamente al mismo tiempo Para lograr esto podemos usar el tiempo en que ocurre el evento, seguido por el número del proceso después del signo decimal P.ej. si ocurren los eventos 1 y 2 ambos en el tiempo 40, entonces el primero se convierte en 40.1 y el segundo en 40.2

Sincronización de relojes físicos Algoritmo de Cristian: supongamos un conjunto de máquinas. Una de ellas tiene acceso a una fuente fiable de la hora (la llamaremos servidor de tiempo) máquina emisora servidor de tiempo T0 solicitud tiempo I, tiempo de procesamiento de la petición T1

Sincronización de relojes físicos Para la máquina emisora, una buena estimación de la hora sería (T1-T0)/2 Y si conocemos el valor de I: (T1-T0-I)/2 Se hacen varias medidas y se toma la media

Sincronización de relojes físicos Algoritmo de Berkeley: en el algoritmo de Cristian, el servidor de tiempo es pasivo. En el UNIX de Berkeley se emplean servidores de tiempo activos El servidor de tiempo realiza un muestreo periódico de todas las máquinas para preguntarles el tiempo Con base en estas respuestas, calcula el tiempo promedio y le indica a las máquinas que avancen o retrasen su reloj la cantidad que sea necesaria

Sincronización de relojes físicos Algoritmos con promedio: los dos métodos anteriores tienen la desventaja de ser centralizados. En este caso dividimos el tiempo en intervalos de resincronización El i-ésimo intervalo comienza en T0+iR y termina en T0+(i+1)R, donde T0 es un momento ya acordado en el pasado y R es una cte. Al comienzo de cada intervalo cada máquina transmite el tiempo actual de su reloj. Puesto que los relojes de las diversas máquinas ni funcionan exactamente a la misma velocidad, estas transmisiones no ocurrirán en forma simultánea Tras transmitir su hora, una máquina arranca un cronómetro local para reunir las demás transmisiones que lleguen en un cierto intervalo S A partir de ellas calcula un nuevo tiempo, p.ej. con la media

Sincronización de relojes físicos Ejemplo de uso de relojes sincronizados: entrega de cómo máximo un mensaje El problema consiste en evitar que un servidor reciba mensajes duplicados El método tradicional es que cada mensaje tenga un nº de mensaje y que el servidor guarde los nºs de mensajes recibidos Si recibe un mensaje con un nº que ya ha visto, lo descarta Pero, ¿qué pasa si el servidor falla y pierde la tabla de los nºs recibidos?, ¿por cuánto tiempo se deben conservar los nºs de los mensajes recibidos?

Sincronización de relojes físicos La solución haciendo uso del tiempo sincronizado consiste en añadir a cada mensaje una marca de tiempo Para cada conexión, el servidor registra en una tabla la marca de tiempo más reciente que haya visto Si la marca de un mensaje recibido es anterior a la guardada, el mensaje se descarta por duplicado Se pueden eliminar las marcas anteriores que sean anteriores a: G=TiempoActual-TiempoMáximodeVidadeMensaje

Exclusión mutua

Exclusión mutua Varios procesos mas fácil programar con regiones criticas . Cuando Pi R o W estructura de datos compartidas : Entra región critica para lograr Exclusión mutua y que ningún otro Proceso R-W esa región de la estructura de datos al mismo tiempo

Exclusión mutua Algoritmo centralizado: La forma más directa de lograrla es similar a la forma en que se hace en un sistema monoprocesador Se elige uno de los procesos en la red como coordinador Cuando un proceso quiere entrar en una región crítica, envía un mensaje de solicitud al proceso coordinador El coordinador decide y responde afirmativamente (OK) o negativamente (no respondiendo o con un mensaje de “permiso denegado”) El coordinador tiene una cola FIFO de las peticiones, por lo que no hay inanición Problemas: el coordinador podría fallar y con él todo el sistema en sistemas grandes el coordinador es un cuello de botella

Algoritmo de Ricart-Agrawala Ricart-Agrawala (1981)El tener un coordinador central que pueda fallar puede ser inaceptable, se han buscado algoritmos distribuidos de exclusion mutua. El primero fue presentado por Lamport (1978). Supongamos que todos los relojes del sistema están sincronizados (p.ej usando el algoritmo de Lamport), de forma que para cualquier par de eventos debe quedar claro cuál ocurrió primero Cuando un proceso quiere entrar en una región crítica construye un mensaje con el nombre de ésta, su número de proceso y la hora actual [Nombre_RC, #Pi, Hora_actual] Envía el mensaje a todos los demás procesos, incluido el

Algoritmo de Ricart-Agrawala (1) Cuando un proceso recibe un mensaje de solicitud de otro proceso: Si el receptor no está en la región crítica y no desea entrar en ella, envía un mensaje OK al emisor Si el receptor ya está en la región crítica, no responde, sino que guarda la solicitud en una lista Si el receptor desea entrar en la región crítica, pero no lo ha logrado todavía, compara la marca de tiempo del mensaje recibido con la marca que él usó en sus mensajes de solicitud: Si el mensaje recibido tiene marca menor, el receptor envía de regreso un mensaje OK Si no, el receptor guarda la solicitud en una lista y no envía nada

Algoritmo de Ricart-Agrawala (2) Nótese que cuando un proceso envía una solicitud, para poder entrar en una región crítica debe esperar a que TODOS los demás procesos le respondan con un mensaje OK Cuando sale de la región crítica envía mensajes OK a todos los procesos en su lista y la vacía

Algoritmo de Ricart-Agrawala (3) Ejemplo: dos procesos 0 y 2, quieren entrar en la región crítica a la vez (Entra en R.C) 12 OK OK OK 8 8 1 2 1 2 1 2 12 OK (Entra en R.C)

Algoritmo de Ricart-Agrawala (4) Problemas del algoritmo: El tráfico de mensajes es mayor que en algoritmo centralizado El algoritmo centralizado tenía un único punto de fallo, pero éste tiene n puntos de fallo ! Si se pierde una respuesta el emisor quedará esperando y no podrá entrar en la sección crítica. Se puede mejorar haciendo que en vez de no responder se envíe el mensaje de “permiso denegado” Redundancia: todos los procesos participan en todas las solicitudes de entrada a una región crítica

Algoritmo Token Ring Algoritmo de paso de fichas: Tenemos una red de bus (Ethernet), pero creamos por software un anillo La posición en el anillo se puede definir p.ej con el orden de las direcciones de red Al principio se le da al proceso 0 del anillo una ficha. La ficha circula por todo el anillo: el proceso k la pasa al proceso k+1 en el anillo mediante un mensaje Un proceso puede entrar en la región crítica solo cuando tenga la ficha. Al salir de la R.C pasa la ficha No se permite entrar en una segunda R.C con la misma ficha

Algoritmo Token Ring (1) El algoritmo del paso de fichas es correcto y no puede existir la inanición Problemas: Si la ficha se pierde es difícil detectar la pérdida, puesto que la cantidad de tiempo entre apariciones sucesivas de la ficha en la red no está acotada (porque un proceso puede retenerla todo el tiempo que pase en la R.C)

Retraso antes de entrar en RC Exclusión mutua M= Mensajes necesarios para q un proceso entre y salga de una R.C Algoritmo M Retraso antes de entrar en RC Problema Centralizado 3 Fallo del coordinador Distribuido 2(n-1) Fallo de cualq. proceso Paso de token 0 a n-1 Token perdido

Elección de coordinador

Introducción Muchos algoritmos distribuidos necesitan que un proceso actúe como coordinador, iniciador, secuenciador o que desempeñe de alguna forma un papel especial Por ej. en el algoritmo de exclusión mutua centralizado Si todos los procesos son iguales , para que tengan ID_UNICO relaciono #red , se suele designar como coordinador al proceso con dirección de red mayor Garantizar que al iniciar una elección esta concluye con el acuerdo de todos los procesos

Algoritmo Bully [Garcia-Molina82] Algoritmo del grandulón: Un proceso P realiza una elección (cuando detecta que el coordinador ha fallado) de la siguiente manera; P envía un mensaje ELECCION a los demás procesos con un número mayor Si nadie responde, P gana la elección y se convierte en el coordinador Si uno de los procesos con número mayor responde, toma el control. Envía un mensaje OK al emisor para indicar que está vivo y que tomará el control El receptor realiza entonces una elección, si no lo está haciendo ya Si un proceso que antes estaba inactivo se activa, realiza una elección. Si ocurre que es el proceso en ejecución con número máximo, se convertirá en el nuevo coordinador

Algoritmo de anillo Se forma un anillo lógico con los procesos, de forma que cada proceso conoce quién es su sucesor Cuando un proceso detecta que el coordinador no funciona, construye un mensaje ELECCION con su propio número de proceso y envía el mensaje a su sucesor. Si éste está inactivo, se lo envía al siguiente En cada paso, el emisor añade su propio nº de proceso a la lista en el mensaje En cierto momento, el mensaje regresa al proceso que lo envió. Ese proceso reconoce ese evento cuando recibe un mensaje de entrada con su propio nº de proceso En ese momento, el mensaje recibido cambia a tipo COORDINADOR y se hace circular de nuevo, para informar a los demás de quién es el nuevo coordinador (el miembro de la lista con el nº máximo)

Transacciones Atómicas

Introducción Abstracción de mayor nivel y se utiliza mucho en sistemas distribuidos: la transacción atómica = acción atómica El modelo original proviene del mundo de los negocios O SE HACE TODO O NO SE HACE NADA

Transacciones atómicas Supongamos un banco al que podemos conectarnos por Internet, con la intención de retirar dinero de nuestra cuenta para transferirlo a otra: Retirar (cantidad, cuenta1) Deposito (cantidad, cuenta2) Si la conexión telefónica falla después de la primera operación pero antes de la segunda ? El problema debe resolverse haciendo que ambas acciones constituyan una transacción atómica: o se hacen ambas o no se hace ninguna

Almacenamiento Podemos tener tres tipos de almacenamiento: Memoria RAM: se borra al fallar la energía o en un fallo de la máquina Disco: sobrevive a fallos anteriores pero podría fallar la cabeza lectora del disco Almacenamiento estable: diseñado para sobrevivir a todo (excepto tal vez a un 11-S) El almacenamiento estable se puede lograr con un par de discos Cuando se quiere escribir se escribe primero en el disco 1 y luego en el disco 2 Si el sistema falla tras escribir en la unidad 1, tras recuperar podemos comprobar que ambos discos son inconsistentes. Hacemos entonces que el 2 copie lo distinto en el 1, pues el 1 es siempre el que se modifica primero Cuando se detecte error (p.ej. por CRC) en un sector de uno de los discos, se repara con la información del otro

Primitivas de transacción Trabajaremos con estas BEGIN_TRANSACTION END_TRANSACTION ABORT_TRANSACTION En medio de una transacción se podrán realizar diversas operaciones ( READ , WRITE), según la aplicación Las transacciones deberán ser todo o nada y además deben ejecutarse en exclusión mutua unas con otras

Propiedades ACID (Atomic Consistent Isolated Durable) Atómicas : para el mundo exterior las transacciones ocurren de manera indivisible Consistentes : las transacción no viola los invariantes del sistema Aisladas : las transacciones concurrentes no interfieren entre si ( Serializability or concurrency atomicity ) Durables: una vez comprometida una transacción , los cambios son permanentes

Implementación espacio de trabajo privado: consiste en mantener una copia de los objetos o memoria que se quiera modificar Por ejemplo, si la transacción implica acceso a un directorio particular, mantenemos una copia Intentamos llevar a cabo la transacción en la copia Si nada falla al final modificamos el original Si no, descartamos la copia

Implementación (1) Bitácora x=0/1 y=0/2 x=1/4 Otra forma de implementarlas es la bitácora La bitácora es una lista de los cambios que se van realizando sobre cada objeto implicado en la transacción En la lista se incluye el estado anterior y posterior del objeto x=0; y=0; BEGIN_TRANSACTION x=x+1; y=y+2; x=y*y; END_TRANSACTION Podemos hacer los cambios en los objetos reales, pues con la bitácora tenemos información para deshacer: partimos del final hacia atrás La bitácora se almacenaría en almacenamiento estable x=0/1 Bitácora y=0/2 x=1/4

Implementación (2) Protocolo de compromiso de dos fases: Uno de los procesos actúa como coordinador El coordinador envía un mensaje de preparado a los demás procesos Y recibe mensajes de los otros procesos indicando si están dispuestos a comprometerse Cuando el coordinador ha recibido todas las respuestas decide si se lleva a cabo la transacción o no Si uno o más procesos no se comprometen (o no responden) la transacción se aborta Si el coordinador decide que se lleva a cabo la transacción, envía un mensaje notificándolo a los demás procesos