Arquitecturas 4pp

Sistemas Operativos Distribuidos
ndice
Introduccin
Arquitecturas para computacin distribuida
Arquitecturas de computacin en Google
Arquitectura de
los Sistemas
Distribuidos
Modelo Map-Reduce y Pregel
Arquitectura cliente-servidor
Variaciones del modelo
Aspectos de diseo del modelo cliente/servidor
Arquitectura editor-subscriptor
Arquitectura Peer-to-peer
Sistemas P2P desestructurados
Sistemas P2P estructurados
Protocolo Chord
2
Arquitecturas de los SD
Grado de acoplamiento
Organizacin lgica de componentes de aplicacin distribuida
Cmo es su patrn de interaccin

Qu roles ejercen los procesos involucrados
Y cul es su correspondencia con nodos de SD fsico
Topologa de la aplicacin distribuida
En principio, tantas como aplicaciones
Arquitecturas ms frecuentes en SD de propsito general

Cliente/servidor
Editor/subscriptor
Peer-to-peer (Paritaria)
Computacin distribuida (CD) presenta sus propios patrones

Maestro/trabajador
Arquitecturas guiadas por la geometra de los datos
2-Arquitecturas de SD
Sea cual sea el modelo, conlleva interaccin entre entidades

Interaccin tradicional implica acoplamiento espacial y temporal
Desacoplamiento espacial (de referencia)
Entidad inicia interaccin no hace referencia directa a la otra entidad
No necesitan conocerse entre s
Desacoplamiento temporal (menos frecuente)
Pero hay patrones que se repiten de forma habitual

3
Fernando Prez Costoya
Vidas de entidades que interaccionan no tienen que coincidir
Ej. Uso de memoria compartida

2 desacoplamientos son independientes entre s
Estos modos de operacin indirectos proporcionan flexibilidad
David Wheeler (el inventor de la subrutina):
All problems in computer science can be solved by another level of
indirection...except for the problem of too many layers of indirection.

4

Arquitecturas para CD
Topologa Cartesian de MPI
Maestro-trabajador M/T (aka maestro-esclavo)

M va repartiendo trabajos entre nodos trabajadores T
Si n trabajos >> n trabajadores reparto automtico de carga
Tolerancia a fallos:
Cada de T: M reasigna sus trabajos pendientes (efectos laterales!)
Cada de M: punto crtico de fallo
Arquitecturas guiadas por geometra de los datos

Matrices multidimensionales, grafos, etc.
P.e. Matriz 2D
Cada nodo se encarga de sub-matriz
Comunicacin ms frecuente con nodos vecinos cartesianos
MPI facilita uso mediante topologas virtuales (Cartesian y Graph)

Permite localizar fcilmente vecinos
Implementacin puede optimizar asignacin a plataforma
5
Arquit. de computacin en Google
int MPI_Cart_create(MPI_Comm comm, int ndims, int *dims, int *periods, int reorder, MPI_Comm *comm_cart);
int MPI_Cart_shift(MPI_Comm comm_cart, int direction, int disp, int *rank_source, int *rank_dest);
Using MPI
William Gropp, Ewing Lusk y Anthony Skjellum (MIT Press)
6
Modelo de computacin Map-Reduce
MapReduce ( 80% de computaciones en Google)
Maestro-trabajador con dos fases: Map y Reduce

Map: T procesa su parte de datos de entrada y genera (clave, valor)
P.ej. Palabras que aparecen en su parte de datos de entrada
Reduce: T procesa valores asociados a una clave
P.ej. Frecuencia de palabras en todos los datos de entrada
Pregel ( 20% de computaciones en Google)
Modelo diseado para procesar grafos de gran escala

Computacin organizada en supersteps sncronos:
Cada vrtice recibe datos de otros vrtices por aristas de entrada

Cambia su estado y genera datos por vrtices de salida
Incluso puede cambiar topologa del grafo
Inspirado en modelo Bulk Synchronous Parallel de Valiant

Implementado como arquitectura maestro/trabajador
M reparte grafo entre T y controla sincronizacin de supersteps

7
Extrado de tutorial sobre MapReduce de Jerry Zhao y Jelena Pjesivac-Grbovic

8

Modelo de computacin Pregel
Arquitecturas en SD de propsito general

Cliente-servidor
Extensin del modelo proveedor/consumidor de servicio a SD
Similar a biblioteca de servicio y programa que la usa pero en SD
Interaccin 1-N
Editor/subscriptor
Extensin de esquema guiado por eventos a SD
Facilita el desacoplamiento espacial y, potencialmente, el temporal
Interaccin M-N
Peer-to-peer
Procesos cooperantes con el mismo rol
Interaccin N-N
Pregel: A System for Large-Scale Graph Processing
Grzegorz Malewicz et al.; SIGMOD 10
9
Modelo cliente/servidor

10
Esquema cliente/servidor
Arquitectura asimtrica: 2 roles en la interaccin
Interfaz de Servicio
Peticin (args.)
Cliente: Solicita servicio
Activo: inicia interaccin
Servidor: Proporciona servicio
Cliente
Pasivo: responde a peticin de servicio
Servidor cuello de botella problemas de escalabilidad

Servidor punto crtico de fallo
Mal aprovechamiento de recursos de mquinas cliente
Normalmente, acoplamiento espacial y temporal

Servidor ofrece coleccin de servicios que cliente debe conocer
Normalmente, peticin especifica recurso, operacin y args.
NFS: READ, file_handle, offset, count
HTTP: GET /index.html HTTP/1.1

11
Resp=Cdigo(args)
Alternativas en diseo de la interfaz de servicio

Operaciones especficas para cada servicio
nfasis en operaciones (acciones)
Mismas ops. para todos servicios pero sobre distintos recursos (REST)
nfasis en recursos: ops. CRUD (HTTP GET, PUT, DELETE, POST)
Ejemplo:
AddBook(nb) vs.
Servidor
Respuesta
Desventajas de arquitectura cliente/servidor

12
PUT /books/ISBN-8448130014 HTTP/1.1


Cliente/servidor con cach
Reparto funcionalidad entre C y S
Mejora latencia, reduce consumo red y recursos servidor

Aumenta escalabilidad
Qu parte del trabajo realiza el cliente y cul el servidor?

Grosor del cliente: Cantidad de trabajo que realiza
Necesidad de coherencia: sobrecarga para mantenerla
Ventajas de clientes ligeros
Mejor operacin en SD La que no usa la red
Pesados (Thick/Fat/Rich Client) vs. Ligeros (Thin/Lean/Slim Client)
Tolera el servicio que cliente use datos obsoletos?

SFD normalmente no; pero servidor de nombres puede que s (DNS)
Puede posibilitar modo de operacin desconectado

CODA
HTML5 Offline Web Applications
Si datos anticipados finalmente no requeridos: gasto innecesario
Para arreglar la falacia 2 hemos estropeado la 3
Posibles repartos entre C y S

Arquitectura tpica de aplicacin basada en 3 capas:
Presentacin (interfaz de usuario grfica: GUI)
Aplicacin: lgica de negocio
Acceso a datos
Pxeles (VNC) o Primitivas grficas (X11)

Cambio de roles: servidor grfico en mquina cliente
GUI
GUI + parte de la lgica de negocio
GUI + lgica de negocio
GUI + lgica de negocio + parte de lgica de acceso
Ej. inteligencia en cliente: Javascript valida letra NIF en form.

14
Cliente/servidor con proxy

Componentes intermediarios entre cliente y servidor
NOTA: Trmino corresponde tambin a un patrn de diseo
Enva eventos de ratn/teclado y recibe info. a dibujar en forma de:

15
Cliente gasta menos recursos de red y de servidor
Ms gil en respuesta al usuario
Actan como tuberas
Qu labor se asigna a mquina cliente? (grosor creciente)
Ventajas de clientes pesados

Mayor autonoma
Mejor escalabilidad
Pre-fetching: puede mejorar latencia de operaciones pero

13
Menor coste de operacin y mantenimiento

Mejor seguridad
Pueden procesar/filtrar informacin y/o realizar labor de cach

Smil con clases FilterInputStream|FilterOutputStream de Java
Diversos tipos: forward proxy, reverse proxy, gateways, ...

Mejor si interfaz de servicio uniforme:
Proxy se comporta como cliente y servidor convencional
Se pueden enganchar sucesivos proxies de forma transparente
Esta caracterstica es una de las claves del xito de la Web

16

Esquema con proxy
Wikipedia: Proxy server
Mejor si Interfaz de Servicio 1 = Interfaz de Servicio 2

Forward
Interfaz de Servicio 1
Peticin (args.)
Cliente
Proxy
Respuesta
Open
Peticin
Interfaz de Servicio 2
Respuesta
Reverse
Servidor
17
Cliente/servidor jerrquico
Servidor nico:
Igual que biblioteca usa servicio de otra biblioteca
Funcionalidad dividida en varios niveles (multi-tier)

P. ej. Aplicacin tpica con 3 capas:
Presentacin
Aplicacin: lgica de negocio
Acceso a datos
Cuello de botella: afecta a latencia y ancho de banda

Punto nico de fallo: afecta a fiabilidad
Uso de mltiples servidores (interaccin M-N)

Si slo uno implicado en servicio reparto de carga
P.ej. leer el valor de un dato replicado en varios servidores

Mejora latencia, escalabilidad y tolerancia a fallos
Si mltiples servidores deben cooperar para ofrecer servicio
Cada nivel puede implementarse como un servidor
Mltiples servidores idnticos cooperan en servicio

Traducir un nombre de fichero en SFD
Traducir de nombre de mquina a IP usando DNS
Cliente/servidor con replicacin
Servidor acta como cliente de otro servicio

19

18
P. ej. actualizar simultneamente dato replicado en varios servidores

Mejora tolerancia a fallos pero no latencia y escalabilidad
Necesidad de coherencia (sobrecarga para mantenerla):
Esquema simtrico: Actualizar simultnea en todas las rplicas

Esquema asimtrico: Actualizar en primario y propagar a secundarios

20

Cliente/servidor con replicacin
Cdigo mvil
Viaja el cdigo en vez de los datos y/o resultados
Requiere:
C
C
C
p
S
p
C
C
Arquitecturas homogneas o
Interpretacin de cdigo o
Mquinas virtuales
Modelos alternativos
Cdigo por demanda (COD)
Servidor enva cdigo a cliente

P.e. applets
Evaluacin remota (REV)
Cliente dispone de cdigo pero ejecucin debe usar recursos servidor

P.ej. Cyber-Foraging
Agentes mviles
Componente autnomo y activo que viaja por SD

21

22
Cdigo por demanda
Evaluacin remota
Peticin
Cliente
Cdigo
Servidor
Peticin(args)+Cdigo
Cliente
Servidor
Respuesta
Resp=Cdigo(args)

23

24
Resp=Cdigo(args)

Aspectos de diseo de cliente/servidor
Localizacin del servidor
Se van a considerar 5 aspectos especficos:
Servidor en mquina con direccin DMS y usando puerto PS
Binder: mantiene correspondencias ID servicio (DMS, PS)
Cmo lo localiza el cliente? Binding

Otro servidor proporciona esa informacin problema huevo-gallina
Localizacin del servidor

Esquemas de servicio a mltiples clientes
Gestin de conexiones
Servicio con estado o sin estado
Comportamiento del servicio ante fallos
Cliente debe conocer direccin y puerto del Binder
Caractersticas deseables de ID de servicio:
mbito global
Mejor nombre de texto de carcter jerrquico (como pathname)
Transparencia de ubicacin
Posible replicacin: ID servicio (DMS1, PS1) | (DMS2, PS2) ....
Posibilidad de migracin de servicio (incluso en mitad de un servicio)
Convivencia de mltiples versiones del servicio
Suele estar englobado en un mecanismo ms general
Servicio de nombres (tema 5): Gestiona IDs de todos los recursos

25

26
Alternativas en la ID del servicio
ID servicio = [DM+pto]
Uso directo de direccin DMS y puerto PS

No proporciona transparencia
Nombre servicio + dir servidor (Java RMI Registry, Sun RPC)

Servidor (binder) en cada nodo: nombre de servicio puerto
Impide migracin del servidor
Nombre de servicio con mbito global (DCE, CORBA, Mach)
Servidor con ubicacin conocida en el sistema

Opcin 1. Slo binder global: nombre de servicio [DMS+PS]
Opcin 2. binder global (BG) + binder local (BL) en puerto conocido
M2
M1
C DM2 + ptoS
DM2 + ptoS
BG: ID [DMS] ; BL: ID [PS]
Uso de cach en clientes para evitar repetir traduccin

Puede haber nivel adicional para facilitar migracin durante servicio
nombre de servicio [ID binario interno] [DMS+PS]
Necesidad de localizacin: Broadcast o Servidor de localizacin

27
Info. de contacto
28
Direccin de servicio

ID servicio = [DM+idsrv]: Alta
ID servicio = [DM+idsrv]: Consulta
M2
2 Idsrv ptoS
M2
Idsrv ptoS
DM2 + ptoB binder
M1
C DM2+idsrv
1
Binder ptoB
Idsrv ptoS
M1
C DM2+idsrv
M2
idsrv?
ptoS
Binder ptoB
Mensaje
M2
DM2 + ptoS S
Info. conocida
DM2 + ptoB binder
DM2 + ptoS S
Binder ptoB
Info. binder

29
ID servicio = [idsrv]; Slo BG: Alta
Binder ptoB
30
ID servicio = [idsrv]; Slo BG: Consulta
M3
Idsrv DM2 + ptoS
M1
C
idsrv
binder DM3+ptoB
M3
idsrv DM2 + ptoS
DM3 + ptoB binder
Idsrv DM2 + ptoS

M2 1
M1
C
idsrv
idsrv?
binder DM3+ptoB
DM2 + ptoS S
binder DM3 +ptoB
31
DM3 + ptoB binder
DM2 + ptoS
2
M2
DM2 + ptoS S
binder DM3 +ptoB

32

ID servicio = [idsrv]; BG+BL: Alta
M1
C
M2
Idsrv ptoS
idsrv
BL ptoL | BG DM3+ptoB
DM2 + ptoL BL
Idsrv ptoS
M2 1
M3
Idsrv DM2
BG DM3 + ptoB
DM2 + ptoS S
4 Idsrv DM2
33
Binding
ID servicio = [idsrv]; BG+BL: Consulta

C
idsrv?
idsrv?
M1
idsrv
M2
M3
BG DM3 + ptoB
Idsrv DM2
34
DM2 + ptoL BL
Idsrv ptoS
1
DM2
ptoS
M2
DM2 + ptoS S
Servicio a mltiples clientes
Caso con BG y BL + versiones:
Servidor secuencial
Servidor:
nico flujo de ejecucin atiende mltiples peticiones
Elige puerto local

Informa a binder local del alta:
Operaciones asncronas y/o espera por mltiples eventos (select/poll)
Uso de mquina de estados para seguimiento de clientes

Solucin compleja y que no aprovecha paralelismo HW
(id. servicio + versin) = puerto
Informa a binder global del alta:
Servidor concurrente
(id. servicio + versin) = dir mquina
Solucin ms natural y que aprovecha paralelismo HW

Threads (T) vs. Procesos (P)
Al terminar, notifica la baja a ambos binder :

Ambos eliminan (id. servicio + versin)
Cliente:
Generalmente threads: Ms ligeros y comparten ms recursos
Consulta a binder global
(id. servicio + versin) dir. mquina
Consulta a binder en dir. mquina

(id. servicio + versin) puerto
35

36

Servicio concurrente: alternativas
Creacin dinmica de T/P segn llegan peticiones
Sobrecarga
Conjunto de N T/P pre-arrancados:
En caso de que se use un esquema con conexin

1 conexin por cada peticin
1 operacin cliente-servidor
conexin, envo de peticin, recepcin de respuesta, cierre de conexin
Al finalizar trabajo, en espera de ms peticiones

Poca carga gasto innecesario
Mucha carga insuficientes
Ms sencillo pero mayor sobrecarga (9 mensajes con TCP!)

Propuestas de protocolos de transporte orientados a C/S (T/TCP)
Varias peticiones de cliente usan misma conexin
Esquema hbrido con mnimo m y mximo M
Ms complejo pero menor sobrecarga

Esquema usado en HTTP/1.1
m pre-arrancados; m T/P M
Si peticin, ninguno libre y n < M se crea
Si inactivo tiempo prefijado y n > m se destruye

37
Gestin de conexiones
Adems, pipeline de peticiones
Implica que servidor mantiene un estado
Servicio con/sin estado

38
Servicio de ficheros con estado: OPEN
Servidor mantiene informacin de clientes?

Ventajas de servicio con estado (aka con sesin remota):
Mensajes de peticin ms cortos
Mejor rendimiento (se mantiene informacin en memoria)
Favorece optimizacin de servicio: estrategias predictivas
Ventajas de servicio sin estado:
Ms tolerantes a fallos (ante rearranque del servidor)
open(f,...)
3
Peticiones autocontenidas.
x N | pos 0
OPEN, f
x
Reduce n de mensajes: no comienzos/finales de sesin.

Ms econmicos para servidor (no consume memoria)
Servicio sin estado base de la propuesta REST

Estado sobre servicios sin estado
f; inodo N
Cliente almacena estado y lo enva al servidor (p.e. HTTP+cookies)

39

40
10

Servicio de ficheros con estado: READ
C
read(3,b,t)
3
Servicio de ficheros con estado: LSEEK
x N | ant+tl
READ, x, t
lseek(3,m,p)
3
DATOS, tl (ledo)
x N | pos p
LSEEK,x,m=SEEK_SET,p
p
f; inodo N

41
f; inodo N
Servicio de ficheros con estado: CLOSE

C
CLOSE, x
Servicio de ficheros sin estado: OPEN

S
open(f,...)
3 N | pos 0
OK
BUSCAR, f
N
f; inodo N

43
close(3)

42
f; inodo N

44
11

Servicio de ficheros sin estado: READ
C
read(3,b,t)
3 N | ant+tl
Servicio de ficheros sin estado: LSEEK

C
lseek(3,m,p)
READ, N, ant, t
3 N | pos p
DATOS, tl (ledo)
f; inodo N

45
f; inodo N
Servicio de ficheros sin estado: CLOSE

C
close(3)
3

46
REST (Representational state transfer)

xito de Web vs. sistemas con interfaces especficos
Arquitectura abstracta C/S base de HTTP/1.1 (Fielding)
Caractersticas principales
Servicios sin estado
Interfaz uniforme centrado en recursos en vez de acciones
Recursos con ID nico (p.e. URI para la web)
Sistema jerrquico: conectores transparentes entre cliente y servidor
Beneficios
f; inodo N

47
Facilita integracin y despliegue independiente de componentes

Facilita incorporacin de tcnicas de caching o polticas de seguridad

48
12

Convenios uso HTTP en servicio RESTful
Leases
Ops. CreateRetrieveUpdateDelete Ops. HTTP

URI representa un recurso o una coleccin de recursos
GET (CRUD)
Mecanismo para mejorar tolerancia a fallos en SD
DELETE (CRUD): Borra recurso o coleccin

PUT (CRUD): Crea (sobrescribe) recurso o coleccin
POST (CRUD)? PUT vs. POST asunto polmico y confuso
Aplicacin tpica (genrica) de leases:
Si URI representa recurso Lo obtiene

Si URI representa coleccin obtiene URIs miembros de coleccin
URI de PUT identifica el recurso que se quiere crear /sobrescribir

URI de POST identifica recurso que manejar contenido de POST
Como parte de procesado puede crear/actualizar recurso
PUT sustituye completamente contenido previo de recurso

POST (no idempotente) permite actualizaciones parciales
49
Leases en servicios con estado

Algunos servicios son inherentemente con estado
P. ej. cerrojos distribuidos
Uso de leases en servicio de cerrojos distribuido

Servidor asigna lease a cliente mientras en posesin de cerrojo
Clientes en posesin de cerrojos deben renovar su lease
Rearranque de S: debe procesar primero peticiones de renovacin
Deteccin y tratamiento de cadas de clientes y servidores
Modo de operacin
Servidor otorga a cliente un lease que dura un plazo de tiempo

Cliente debe renovar lease antes de fin de plazo
Servidor gestiona algn tipo de recurso vinculado con un cliente
Excepto por leases, cliente no tiene por qu contactar con servidor
Si cliente cae y no renueva el lease, recurso abandonado

Si servidor cae, en reinicio obtiene renovaciones
Puede reconstruir los recursos
No confundir con un simple temporizador
Cliente enva peticin a servidor y arranca temporizador
Si se cumple antes de ACK, vuelve a enviar peticin ( lease)

50
Serv. cerrojos con estado: leases (1)

C1
C2
C3
lock(m1)
lock(m2)
lock(m3)
..............
..............
..............
unlock(m1)
unlock(m2)
unlock(m3)
Tiempo de reinicio de servicio > tiempo de renovacin
Reconstruccin automtica de estado despus de rearranque de S

Cada de cliente: falta de renovacin
Revocacin automtica de cerrojos de ese cliente
m1 libre
m2 C2
m3 libre
51
c1 lock(m1) cola de mensajes de S

c2 lease(m2)

52
S
13

C1
C2
C3

C1
C2
C3
lock(m1)
lock(m2)
lock(m3)
lock(m1)
lock(m2)
lock(m3)
..............
..............
..............
..............
..............
..............
unlock(m1)
unlock(m2)
unlock(m3)
unlock(m1)
unlock(m2)
unlock(m3)
m1 C1
m2 C2
m3 libre
c1 lease(m1) cola de mensajes de S

c2 lease(m2)
S

53

C1
C2
C3
cola de mensajes de S
m1 C1
m2 C2
m3 libre

54

C1
C2
C3
lock(m1)
lock(m2)
lock(m3)
lock(m1)
lock(m2)
lock(m3)
..............
..............
..............
..............
..............
..............
unlock(m1)
unlock(m2)
unlock(m3)
unlock(m1)
unlock(m2)
unlock(m3)
c1 lease(m1)
c3 lock(m3) cola de mensajes de S
c2 lease(m2)
Treinicio>Tlease S

55
m1 C1
m2 C2
m3 libre
c3 lock(m3)

56
cola de mensajes de S
S
14

Comportamiento del servicio ante fallos
Qu se garantiza con respecto al servicio ante fallos?
Nada: Servicio puede ejecutar 0 a N veces

Al menos una vez (1 a N veces)
Como mucho una vez (0 1 vez)
Exactamente una vez: Sera lo deseable
Fallos con comunicacin fiable

Si cae servidor no siempre puede saber si ejecutado servicio
Semntica de como mucho una vez
Si llega respuesta, se ha ejecutado exactamente una vez
Si no llega (servidor cado), se ha ejecutado 0 1 vez
Para semntica al menos una vez (con ops. idempotentes)
Operaciones repetibles (idempotentes)

Cuenta += cantidad (NO)
Cuenta = cantidad (S)
Operacin idempotente + al menos 1 vez exactamente 1

Tipos de fallos:
Retransmitir hasta respuesta (servidor se recupere) o fin de plazo

Usar un sistema de transacciones distribuidas
Prdida de peticin o de respuesta (slo si comunicacin no fiable)

Cada del servidor
Cada del cliente

57

58
Fallos con comunicacin no fiable

Prdida de peticin/respuesta
Si operacin idempotente, no es errneo pero gasta recursos

Si no, es errneo
Se puede guardar histrico de respuestas (cach de respuestas):

Si n de secuencia duplicado, no se ejecuta pero manda respuesta
Cada del servidor

Si llega finalmente respuesta, semntica de al menos una vez
Si no llega, no hay ninguna garanta (0 a N veces)
Cada del cliente

Menos traumtica: problema de computacin hurfana
Si no respuesta, retransmisin cuando se cumple plazo

N de secuencia en mensaje de peticin
Si prdida de peticin, retransmisin no causa problemas
Si prdida de respuesta, retransmisin causa re-ejecucin

59
Gasto de recursos intil en el servidor
Alternativas:
Uso de pocas:
Peticiones de cliente llevan asociadas un n de poca
En rearranque de cliente C: transmite (++n de poca) a servidores
Servidor aborta servicios de C con n de poca menor
Uso de leases:
Servidor asigna lease mientras dura el servicio
Si cliente no renueva lease se aborta el servicio
Abortar un servicio no es trivial

Puede dejar incoherente el estado del servidor (p.e. cerrojos)
60
15

Modelo editor/subscriptor
Modelo editor/subscriptor
Sistema de eventos distribuidos (Jini, s. eventos/notifi. CORBA)

Suscriptor S (subscriber) muestra inters por eventos
Se subscribe a ciertos eventos: filtro por tipo, por tema, por contenido
Su1
suscribe(ev5)
notifica(ev5)
Su2
suscribe(ev3)
Su3
suscribe(ev5)
notifica(ev5)
Editor E (publisher) genera un evento
Se enva a subscriptores interesados en el mismo
Ops.: suscribir [alta/baja] (S); publicar (E); notificar (S)

Paradigma asncrono y desacoplado en espacio
Editores y subscriptores no se conocen entre s ( cliente/servidor)
En algunos casos tambin desacoplado en el tiempo
Normalmente, push: suscriptor recibe notificaciones
Su4
Alternativa, pull: suscriptor pregunta si hay notificaciones
Ed1
publica(ev5)
Ed2
Ed3
suscribe(ev1)
Calidad de servicio (orden entrega o prdida de notificaciones)

Posible uso de leases en suscripcin
61
Ejemplo editor/suscriptor

62
Cliente/servidor vs. Editor/suscriptor
Mercado burstil
Tipo de evento
Cl
Ed
genera
datos
Cada valor (V) del mercado
genera
datos
Subscriptor
Proceso interesado (PI) en operaciones sobre un determinado valor
Editores
Proceso que realiza operaciones (PO) sobre un determinado valor
POi realiza operacin sobre Vj

Envo de notificacin a todo PIk suscrito a Vj
imprime
datos
almacena
datos
proyecta
datos
imprime
datos
almacena
datos
proyecta
datos
Se1
Se2
Se3
Su1
Su2
Su3
En cul es ms fcil aadir nuevo consumidor de datos?

63

64
16

Implementaciones editor/suscriptor
Modelo Peer-to-Peer (P2P)

Todos los nodos tienen mismo rol y funcionalidad (servents)
Su1
Su2
Su1
Ed1
Su2
Ed2
Su3
Su4
Su1
Ed1
Int.
Su2
Ed2
Su3
Ed3
Contacto directo ed./ suscr.

Acoplamiento espacial
Su3
Ed3
Su4
Int.
Su4
Ed1
Se suelen caracterizar adems por:
Int.
Ed2
Int.
Ed3
Volatilidad: Nodos entran y salen del SD; variabilidad en conectividad

Capacidad de autogestin sin una autoridad global centralizada
Dedicados a compartir recursos (contenidos,UCP,almacn,...)

Y/O a colaboracin y comunicacin entre usuarios
Uso de red superpuesta (overlay): Red lgica sobre la fsica
Proceso intermediario
Red de intermediarios
Desacoplamiento espacial
Desacoplamiento espacial
Cuello botella y punto fallo
Escalabilidad y fiabilidad

65
No hay cuellos de botella ni puntos crticos de fallo

Se aprovechan recursos de todas las mquinas
Esquema Peer-to-Peer (P2P)
Nodos de proceso como nodos de red

Esquemas de encaminamiento y localizacin de recursos
Desventajas de arquitectura P2P
Difcil administracin y mayores problemas de seguridad

66
Tipos de sistemas P2P

Desestructurados:
Entidad
Topologa de conexin lgica arbitraria

Ubicacin de recursos impredecible e independiente de la topologa
Entidad
Entidad
Cada nodo posee un conjunto de recursos
Entidad
Entidad
Entidad
Corresponden a sistemas +voltiles con nodos ms autnomos
Entidad
Entidad
Estructurados:
Entidad
nica op.: lookup(clave recurso) dir IP mquina que posee recurso

Protocolos Chord (Stoica et al. MIT 2001), CAN, Tapestry y Pastry
Corresponden a sistemas -voltiles con nodos ms cooperativos
Interfaz de Dilogo
67
Topologa de conexin prefijada (p.e. anillo en protocolo Chord)

Ubicacin de recursos predecible y dependiente de la topologa
Generalmente definida por funcin hash distribuida
Posesin de recursos cambia segn sistema evoluciona


68
17

Tipos de sistemas P2P desestructuradas
Localizacin recursos en redes hbridas
Hbridos: P2P + Cliente/servidor (p.e. Napster)

Servidor central guarda informacin encaminamiento y localizacin
Altas y bajas de nodos contactan con servidor
Localizacin de recursos consulta al servidor
Puramente descentralizados (p.e. versin original de Gnutella)

Todos los nodos con la misma funcionalidad
Nodos propagan entre s conocimiento de otros nodos
Localizacin de recursos por inundacin
Parcialmente centralizados (p.e. Kazaa)

Sper-nodos con info. encaminamiento y localizacin de grupo nodos
Pero dinmicamente elegidos y asignados
A Survey of Peer-to-Peer Content Distribution Technologies
S. Androutsellis-Theotokis y D. Spinellis; ACM Computing Surveys, 2004
69
Localizacin recursos en redes puras

70
Protocolo Chord
Hashing consistente asigna ID a clave recurso y a IP de nodo
ID con m bits tal que n recursos (K) + n nodos (N) << 2m
IDs organizados en anillo mdulo 2m
Proporciona distribucin uniforme
Asignacin de recurso K a nodo N
1er nodo ID(N) ID(K) sucesor(K) (NOTA: siguiendo mdulo)
Localizacin de recurso: N busca K; algoritmo simple

Cada nodo slo necesita almacenar quin es su sucesor directo
NOTA: nodo almacena tambin predecesor
A Survey of Peer-to-Peer Content Distribution Technologies
Bsqueda lineal de sucesor a sucesor

Hasta encontrar par de nodos a, b tal que ID (a, b]
Ineficiente y no escalable O(N)
S. Androutsellis-Theotokis y D. Spinellis; ACM Computing Surveys, 2004

71

72
18

Anillo 26 con 10 nodos y 5 recursos
Chord: A Scalable Peer-to-peer Lookup Service for Internet Applications

Ion Stoica et al.; ACM SIGCOMM01
73
Bsqueda simple lineal

Bsqueda basada en fingers

74
Fingers en anillo 24
Cada nodo con ID n incluye tabla fingers TF con m entradas:

Entrada i: primer nodo a una distancia 2i-1
sucesor(n + 2i-1) tal que 1 i m
Entrada 0: sucesor directo
Bsqueda de K desde nodo n:
Si ID (n, s: sucesor directo de n] K asignado a s

Sino: buscar en TF empezando por Entrada m:
Nodo ms inmediatamente precedente
Pedirle que contine la bsqueda
Tiempo localizacin e info. requerida: O(logN)
Wikipedia Chord
75

76
19

Bsqueda en anillo 24
Bsqueda con fingers

Wikipedia Chord
77
Mantenimiento del anillo

78
Alta de un nodo
Operacin join de nodo N:
Carcter dinmico del anillo
Conoce de alguna forma dir. de cualquier nodo existente N

N calcula su ID y pide a N bsqueda de su sucesor
N anota su sucesor (por ahora predecesor = NULO)
Alta de nodos
Baja voluntaria de nodos
Baja involuntaria de nodos (cadas)
Operaciones deben asegurar estabilidad del anillo

Descompuestas en varios pasos cuidadosamente ideados
Procesos peridicos de actualizacin del anillo
Operacin peridica en cada nodo stabilize:
Pregunta a su sucesor S por su predecesor P

Si P mejor sucesor de N que S, fija P como sucesor de S
Notifica a su sucesor para que reajuste predecesor, si necesario
Operacin peridica en cada nodo fix_fingers:
Aseguran estabilizacin antes cambios continuos
Actualizacin de tabla de fingers si necesario
Operacin peridica en cada nodo check_predecessor:
Comprueba si sigue vivo predecesor: No predecesor = NULO
Alta incluye transferencia de recursos asociados ahora a N

79

80
20

Alta de un nodo
Alta de un nodo: paso a paso
Np
Ns
Np
Ns
Np
Ns
Np
Ns
Nn
Nn
Nn
Nn
Estado
inicial
join(Nn)
stabilize(Nn)
stabilize(Np)

81
Baja de un nodo

82
Tablas finger despus de alta y baja
Baja voluntaria de nodo implica acciones complementarias

Devolver recursos a nuevo sucesor
Informar a predecesor y sucesor para que reajusten estado
Cada de nodo (baja involuntaria) ms problemtica

Operaciones peridicas de estabilizacin van reajustando el anillo
Pero puede haber problemas en bsqueda hasta reajuste
Nodo sucesor cado hasta que se actualiza nuevo sucesor
Solucin: Cada nodo guarda lista de sus m sucesores

Qu pasa con los recursos del nodo cado?
Protocolo no especifica poltica de replicacin de recursos
Algoritmo estable ante altas y bajas simultneas

Es capaz de trabajar con info. no totalmente actualizada


83

84
21

Arquitecturas 4pp

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Arquitecturas 4pp

Transféré par

Droits d'auteur :

Formats disponibles

Sistemas Operativos Distribuidos

Sistemas Operativos Distribuidos

Modelo Map-Reduce y Pregel

Organizacin lgica de componentes de aplicacin distribuida

Cmo es su patrn de interaccin

En principio, tantas como aplicaciones

Arquitecturas ms frecuentes en SD de propsito general

Computacin distribuida (CD) presenta sus propios patrones

Sea cual sea el modelo, conlleva interaccin entre entidades

Desacoplamiento temporal (menos frecuente)

Pero hay patrones que se repiten de forma habitual

Sistemas Operativos Distribuidos

Fernando Prez Costoya

Fernando Prez Costoya

Vidas de entidades que interaccionan no tienen que coincidir

Ej. Uso de memoria compartida

Sistemas Operativos Distribuidos

Fernando Prez Costoya

Sistemas Operativos Distribuidos

Topologa Cartesian de MPI

Maestro-trabajador M/T (aka maestro-esclavo)

Si n trabajos >> n trabajadores reparto automtico de carga

Arquitecturas guiadas por geometra de los datos

MPI facilita uso mediante topologas virtuales (Cartesian y Graph)

Fernando Prez Costoya

Arquit. de computacin en Google

Fernando Prez Costoya

Modelo de computacin Map-Reduce

MapReduce ( 80% de computaciones en Google)

Maestro-trabajador con dos fases: Map y Reduce

Reduce: T procesa valores asociados a una clave

P.ej. Frecuencia de palabras en todos los datos de entrada

Pregel ( 20% de computaciones en Google)

Modelo diseado para procesar grafos de gran escala

Cada vrtice recibe datos de otros vrtices por aristas de entrada

Inspirado en modelo Bulk Synchronous Parallel de Valiant

M reparte grafo entre T y controla sincronizacin de supersteps

Sistemas Operativos Distribuidos

Fernando Prez Costoya

Extrado de tutorial sobre MapReduce de Jerry Zhao y Jelena Pjesivac-Grbovic

Fernando Prez Costoya

Sistemas Operativos Distribuidos

Arquitecturas en SD de propsito general

Fernando Prez Costoya

Sistemas Operativos Distribuidos

Fernando Prez Costoya

Arquitectura asimtrica: 2 roles en la interaccin

Cliente: Solicita servicio

Activo: inicia interaccin

Servidor: Proporciona servicio

Pasivo: responde a peticin de servicio

Servidor cuello de botella problemas de escalabilidad

Normalmente, acoplamiento espacial y temporal

Sistemas Operativos Distribuidos

Alternativas en diseo de la interfaz de servicio

Fernando Prez Costoya

Desventajas de arquitectura cliente/servidor

Sistemas Operativos Distribuidos

PUT /books/ISBN-8448130014 HTTP/1.1

Sistemas Operativos Distribuidos

Reparto funcionalidad entre C y S

Mejora latencia, reduce consumo red y recursos servidor

Qu parte del trabajo realiza el cliente y cul el servidor?