1 comunicación en grupos. 2 bibliografía sistemas operativos distribuidos a. s. tanenbaum,...
TRANSCRIPT
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
Introducción
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
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
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
Membresía (Group Membership)
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
Direccionamiento al Grupo
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:
0 1 2 3 40
1
2
3
4
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: mensaje de 4 mensaje de 0
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
A
B
C
D
0 1
23
G1G2
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
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
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
Comunicación en Grupo en ISIS (1)
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 ABCASTProtocolo 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
Primitivas de Comunicación
Primitiva CBCAST
0468215
1378215
2358215
3378215
4268215
5378315
Aceptado Delay Aceptado Delay Aceptado
Estado de los Vectores en los otros nodos
Vector en un Mensaje
enviado por Po
1) Vj = Lj + 12) Vi <= Li para todo i <> j
Condiciones para aceptar un Mensaje
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!
máquina queejecuta el compilador
máquina queejecuta el editor
tiempo delreloj local
tiempo delreloj local
2144 2145 2146 2147
2142 2143 2144 2145
output.o creado
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 ab 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 ab 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 ab es verdadero
“ocurre antes de” es una relacion transitiva : Si ab y bc ac
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 ab 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
0
6
12
18
24
30
36
42
48
54
60
0
8
16
24
32
40
48
56
64
72
80
0
10
20
30
40
50
60
70
80
90
100
A
B
C
D
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
29
Sincronización de relojes lógicos
0
6
12
18
24
30
36
42
48
70
76
0
8
16
24
32
40
48
61
69
77
85
0
10
20
30
40
50
60
70
80
90
100
A
B
C
D
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
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)
T0
T1
máquina emisora servidor de tiempo
I, tiempo de procesamiento de la petición
tiemp
o
solicitud
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
0
1 2
8 812
12
0
1 2
OK
OK
OK
(Entra en R.C)
0
1 2
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
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 3 Fallo del coordinador
Distribuido 2(n-1) 2(n-1) Fallo de cualq. proceso
Paso de token
0 a n-1 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_TRANSACTIONEND_TRANSACTIONABORT_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)
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
x=0/1
Bitácora
y=0/2
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