Arquitecturas 1pp

Sistemas Operativos Distribuidos
Arquitectura de
los Sistemas
Distribuidos
ndice
Introduccin
Arquitecturas para computacin distribuida
Arquitecturas de computacin en Google
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
Fernando Prez Costoya
Arquitecturas de los SD
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
Pero hay patrones que se repiten de forma habitual
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

3
Grado de acoplamiento
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)
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
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
Topologa Cartesian de MPI
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
Arquit. de computacin en Google

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
Modelo de computacin Map-Reduce
Extrado de tutorial sobre MapReduce de Jerry Zhao y Jelena Pjesivac-Grbovic

8
Modelo de computacin Pregel
Pregel: A System for Large-Scale Graph Processing

Grzegorz Malewicz et al.; SIGMOD 10
9
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

10
Modelo cliente/servidor
Arquitectura asimtrica: 2 roles en la interaccin
Cliente: Solicita servicio
Activo: inicia interaccin
Servidor: Proporciona servicio
Pasivo: responde a peticin de servicio
Desventajas de arquitectura cliente/servidor
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
Esquema cliente/servidor
Interfaz de Servicio
Peticin (args.)
Cliente
Servidor
Respuesta
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.

12
PUT /books/ISBN-8448130014 HTTP/1.1

Cliente/servidor con cach

Mejora latencia, reduce consumo red y recursos servidor
Aumenta escalabilidad
Mejor operacin en SD La que no usa la red
Necesidad de coherencia: sobrecarga para mantenerla

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
Pre-fetching: puede mejorar latencia de operaciones pero

Si datos anticipados finalmente no requeridos: gasto innecesario
Para arreglar la falacia 2 hemos estropeado la 3
13
Reparto funcionalidad entre C y S

Qu parte del trabajo realiza el cliente y cul el servidor?
Grosor del cliente: Cantidad de trabajo que realiza
Pesados (Thick/Fat/Rich Client) vs. Ligeros (Thin/Lean/Slim Client)
Ventajas de clientes ligeros

Menor coste de operacin y mantenimiento
Mejor seguridad
Ventajas de clientes pesados

Mayor autonoma
Mejor escalabilidad
Cliente gasta menos recursos de red y de servidor
Ms gil en respuesta al usuario
Ej. inteligencia en cliente: Javascript valida letra NIF en form.

14
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
Qu labor se asigna a mquina cliente? (grosor creciente)

Enva eventos de ratn/teclado y recibe info. a dibujar en forma de:
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

15
Cliente/servidor con proxy

Componentes intermediarios entre cliente y servidor
NOTA: Trmino corresponde tambin a un patrn de diseo
Actan como tuberas

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

Mejor si Interfaz de Servicio 1 = Interfaz de Servicio 2
Interfaz de Servicio 1
Peticin (args.)
Cliente
Respuesta
Proxy
Interfaz de Servicio 2
Respuesta
Peticin
Servidor
17
Wikipedia: Proxy server

Forward
Open
Reverse

18
Cliente/servidor jerrquico
Servidor acta como cliente de otro servicio
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
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

19
Cliente/servidor con replicacin

Servidor nico:
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
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
C
C
C
p
S
p
C
C

21
Cdigo mvil
Viaja el cdigo en vez de los datos y/o resultados
Requiere:
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

22
Cdigo por demanda
Peticin
Cliente
Cdigo
Servidor
Resp=Cdigo(args)

23
Evaluacin remota
Peticin(args)+Cdigo
Cliente
Servidor
Respuesta

24
Resp=Cdigo(args)
Aspectos de diseo de cliente/servidor

Se van a considerar 5 aspectos especficos:
Localizacin del servidor

Esquemas de servicio a mltiples clientes
Gestin de conexiones
Servicio con estado o sin estado
Comportamiento del servicio ante fallos

25
Localizacin del servidor

Servidor en mquina con direccin DMS y usando puerto PS
Cmo lo localiza el cliente? Binding

Otro servidor proporciona esa informacin problema huevo-gallina
Binder: mantiene correspondencias ID servicio (DMS, PS)

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

26
Alternativas en la ID del servicio

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
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
ID servicio = [DM+pto]
M2
M1
C DM2 + ptoS
Info. de contacto
28
DM2 + ptoS
Direccin de servicio
ID servicio = [DM+idsrv]: Alta

M2
2 Idsrv ptoS
DM2 + ptoB binder
M1
C DM2+idsrv
1
Binder ptoB
Idsrv ptoS
M2
DM2 + ptoS S
Info. conocida
Mensaje

29
Info. binder
Binder ptoB
ID servicio = [DM+idsrv]: Consulta

M2
Idsrv ptoS
M1
C DM2+idsrv
DM2 + ptoB binder
idsrv?
Binder ptoB
ptoS
2
M2
DM2 + ptoS S
Binder ptoB

30
ID servicio = [idsrv]; Slo BG: Alta

M3
Idsrv DM2 + ptoS
M1
C
idsrv
binder DM3+ptoB
DM3 + ptoB binder
Idsrv DM2 + ptoS

M2 1
DM2 + ptoS S
binder DM3 +ptoB

31
ID servicio = [idsrv]; Slo BG: Consulta

M3
idsrv DM2 + ptoS
M1
C
idsrv
DM3 + ptoB binder
idsrv?
binder DM3+ptoB
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
4 Idsrv DM2
33
DM2 + ptoS S
ID servicio = [idsrv]; BG+BL: Consulta

C
idsrv?
idsrv?
M1
idsrv
M2
Idsrv ptoS
1
DM2
M3
BG DM3 + ptoB
Idsrv DM2
34
ptoS
DM2 + ptoL BL
M2
DM2 + ptoS S
Binding
Caso con BG y BL + versiones:
Servidor:
Elige puerto local
Informa a binder local del alta:
(id. servicio + versin) = puerto
Informa a binder global del alta:

(id. servicio + versin) = dir mquina
Al terminar, notifica la baja a ambos binder :

Ambos eliminan (id. servicio + versin)
Cliente:
Consulta a binder global
(id. servicio + versin) dir. mquina
Consulta a binder en dir. mquina
(id. servicio + versin) puerto

35
Servicio a mltiples clientes

Servidor secuencial
nico flujo de ejecucin atiende mltiples peticiones
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
Servidor concurrente
Solucin ms natural y que aprovecha paralelismo HW
Threads (T) vs. Procesos (P)
Generalmente threads: Ms ligeros y comparten ms recursos

36
Servicio concurrente: alternativas

Creacin dinmica de T/P segn llegan peticiones
Sobrecarga
Conjunto de N T/P pre-arrancados:

Al finalizar trabajo, en espera de ms peticiones
Poca carga gasto innecesario
Mucha carga insuficientes
Esquema hbrido con mnimo m y mximo M

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

Ms complejo pero menor sobrecarga
Esquema usado en HTTP/1.1
Adems, pipeline de peticiones
Implica que servidor mantiene un estado

38
Servicio con/sin estado

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)

Peticiones autocontenidas.
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
Cliente almacena estado y lo enva al servidor (p.e. HTTP+cookies)

39
Servicio de ficheros con estado: OPEN

C
open(f,...)
3
x N | pos 0
OPEN, f
x
f; inodo N

40
Servicio de ficheros con estado: READ

C
read(3,b,t)
3
x N | ant+tl
READ, x, t
DATOS, tl (ledo)
f; inodo N

41
Servicio de ficheros con estado: LSEEK

C
lseek(3,m,p)
3
x N | pos p
LSEEK,x,m=SEEK_SET,p
p
f; inodo N

42
Servicio de ficheros con estado: CLOSE

C
close(3)
3
CLOSE, x
OK
f; inodo N

43
Servicio de ficheros sin estado: OPEN

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

44
Servicio de ficheros sin estado: READ

C
read(3,b,t)
3 N | ant+tl
READ, N, ant, t
DATOS, tl (ledo)
f; inodo N

45
Servicio de ficheros sin estado: LSEEK

C
lseek(3,m,p)
3 N | pos p
f; inodo N

46
Servicio de ficheros sin estado: CLOSE

C
close(3)
3
f; inodo N

47
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
Facilita integracin y despliegue independiente de componentes
Facilita incorporacin de tcnicas de caching o polticas de seguridad

48
Convenios uso HTTP en servicio RESTful

Ops. CreateRetrieveUpdateDelete Ops. HTTP
URI representa un recurso o una coleccin de recursos
GET (CRUD)
Si URI representa recurso Lo obtiene

Si URI representa coleccin obtiene URIs miembros de coleccin
DELETE (CRUD): Borra recurso o coleccin

PUT (CRUD): Crea (sobrescribe) recurso o coleccin
POST (CRUD)? PUT vs. POST asunto polmico y confuso
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
Mecanismo para mejorar tolerancia a fallos en SD
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
Aplicacin tpica (genrica) de leases:
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
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
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

51
Serv. cerrojos con estado: leases (1)

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

c2 lease(m2)

52
S

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

c2 lease(m2)

53
S

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

C1
C2
C3
lock(m1)
lock(m2)
lock(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

C1
C2
C3
lock(m1)
lock(m2)
lock(m3)
..............
..............
..............
unlock(m1)
unlock(m2)
unlock(m3)
m1 C1
m2 C2
m3 libre
c3 lock(m3)

56
cola de mensajes de S
S
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
Operaciones repetibles (idempotentes)

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

Tipos de fallos:
Prdida de peticin o de respuesta (slo si comunicacin no fiable)

Cada del servidor
Cada del cliente

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

Retransmitir hasta respuesta (servidor se recupere) o fin de plazo
Usar un sistema de transacciones distribuidas

58
Fallos con comunicacin no fiable

Prdida de peticin/respuesta
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
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)
59
Cada del cliente

Menos traumtica: problema de computacin hurfana
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
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
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
Alternativa, pull: suscriptor pregunta si hay notificaciones
Calidad de servicio (orden entrega o prdida de notificaciones)

Posible uso de leases en suscripcin
61
Modelo editor/subscriptor
Su1
suscribe(ev5)
notifica(ev5)
Su2
suscribe(ev3)
Su3
Su4
Ed1
publica(ev5)
suscribe(ev5)
notifica(ev5)
suscribe(ev1)

62
Ed2
Ed3
Ejemplo editor/suscriptor
Mercado burstil
Tipo de evento
Cada valor (V) del mercado
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

63
Cliente/servidor vs. Editor/suscriptor

Cl
Ed
genera
datos
genera
datos
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?

64
Implementaciones editor/suscriptor
Su1
Su2
Ed1
Ed2
Su3
Su4
Su1
Su2
Ed1
Int.
Ed2
Su3
Ed3
Su4
Ed3
Su1
Int.
Su2
Su3
Su4
Ed1
Int.
Ed2
Int.
Ed3
Contacto directo ed./ suscr.
Proceso intermediario
Red de intermediarios
Acoplamiento espacial
Desacoplamiento espacial
Desacoplamiento espacial
Cuello botella y punto fallo
Escalabilidad y fiabilidad

65
Modelo Peer-to-Peer (P2P)

Todos los nodos tienen mismo rol y funcionalidad (servents)
No hay cuellos de botella ni puntos crticos de fallo
Se aprovechan recursos de todas las mquinas
Se suelen caracterizar adems por:
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

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
Esquema Peer-to-Peer (P2P)
Entidad
Entidad
Entidad
Entidad
Entidad
Entidad
Entidad
Entidad
Entidad
Interfaz de Dilogo

67
Tipos de sistemas P2P

Desestructurados:
Topologa de conexin lgica arbitraria
Ubicacin de recursos impredecible e independiente de la topologa
Cada nodo posee un conjunto de recursos
Corresponden a sistemas +voltiles con nodos ms autnomos
Estructurados:
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
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

Posesin de recursos cambia segn sistema evoluciona
68
Tipos de sistemas P2P desestructuradas

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

69
Localizacin recursos en redes hbridas
A Survey of Peer-to-Peer Content Distribution Technologies

S. Androutsellis-Theotokis y D. Spinellis; ACM Computing Surveys, 2004
70
Localizacin recursos en redes puras
A Survey of Peer-to-Peer Content Distribution Technologies

S. Androutsellis-Theotokis y D. Spinellis; ACM Computing Surveys, 2004
71
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
Bsqueda lineal de sucesor a sucesor

Hasta encontrar par de nodos a, b tal que ID (a, b]
Ineficiente y no escalable O(N)
72
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

74
Bsqueda basada en fingers

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)

75
Fingers en anillo 24
Wikipedia Chord
76
Bsqueda en anillo 24
Wikipedia Chord
77
Bsqueda con fingers

78
Mantenimiento del anillo

Carcter dinmico del anillo
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

Aseguran estabilizacin antes cambios continuos

79
Alta de un nodo
Operacin join de nodo N:
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)
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:

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

80
Alta de un nodo

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

82
Baja de un nodo
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
Tablas finger despus de alta y baja

84

Arquitecturas 1pp

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Arquitecturas 1pp

Cargado por

Copyright:

Formatos disponibles

Sistemas Operativos Distribuidos

Fernando Prez Costoya

Cmo es su patrn de interaccin

En principio, tantas como aplicaciones

Pero hay patrones que se repiten de forma habitual

Arquitecturas ms frecuentes en SD de propsito general

Computacin distribuida (CD) presenta sus propios patrones

Sistemas Operativos Distribuidos

Fernando Prez Costoya

Desacoplamiento temporal (menos frecuente)

Vidas de entidades que interaccionan no tienen que coincidir

Ej. Uso de memoria compartida

Sistemas Operativos Distribuidos

Fernando Prez Costoya

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

Topologa Cartesian de MPI

Fernando Prez Costoya

Arquit. de computacin 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

Modelo de computacin Map-Reduce

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

Fernando Prez Costoya

Modelo de computacin Pregel

Pregel: A System for Large-Scale Graph Processing

Fernando Prez Costoya

Arquitecturas en SD de propsito general

Sistemas Operativos Distribuidos

Fernando Prez Costoya

Activo: inicia interaccin

Servidor: Proporciona servicio

Pasivo: responde a peticin de servicio

Desventajas de arquitectura cliente/servidor

Servidor cuello de botella problemas de escalabilidad

Normalmente, acoplamiento espacial y temporal

Sistemas Operativos Distribuidos

Fernando Prez Costoya

Alternativas en diseo de la interfaz de servicio

Sistemas Operativos Distribuidos

PUT /books/ISBN-8448130014 HTTP/1.1

Cliente/servidor con cach

Necesidad de coherencia: sobrecarga para mantenerla

Puede posibilitar modo de operacin desconectado

Pre-fetching: puede mejorar latencia de operaciones pero

Fernando Prez Costoya

Reparto funcionalidad entre C y S

Ventajas de clientes ligeros

Ventajas de clientes pesados

Ms gil en respuesta al usuario

Ej. inteligencia en cliente: Javascript valida letra NIF en form.

Fernando Prez Costoya

Posibles repartos entre C y S