Comunicación en Grupos

Presentación del tema: "Comunicación en Grupos"— Transcripción de la presentación:

1 Comunicación en Grupos

2 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

3 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

4 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 .

5 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

6 Comunicación a nivel de Red
Multicasting Broadcasting Unicasting

7 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

8 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

9 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

10 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

11 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

12 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 .

13 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

14 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

15 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

16 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

17 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

18 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

19 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

20 Sincronización en DS

21 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 .

22 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?

23 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

24 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

25 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

26 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

27 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

28 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

29 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

30 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

31 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

32 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

33 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

34 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

35 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?

36 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

37 Exclusión mutua

38 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

39 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

40 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

41 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

42 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

43 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)

44 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

45 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

46 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)

47 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

48 Elección de coordinador

49 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

50 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

51 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)

52 Transacciones Atómicas

53 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

54 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

55 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

56 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

57 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

58 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

59 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

60 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