Si Stems Dis Tribu I Dps

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
Sistemas Operativos Distribuidos 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

Cliente/servidor Editor/subscriptor Peer-to-peer (Paritaria)
Pero hay patrones que se repiten de forma habitual
Arquitecturas ms frecuentes en SD de propsito general
Computacin distribuida (CD) presenta sus propios patrones

Maestro/trabajador Arquitecturas guiadas por la geometra de los datos
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.
Fernando Prez Costoya
Sistemas Operativos Distribuidos 4
Arquitecturas para CD
Maestro-trabajador M/T (aka maestro-esclavo)
M va repartiendo trabajos entre nodos trabajadores T Tolerancia a fallos:
Cada de T: M reasigna sus trabajos pendientes (efectos laterales!) Cada de M: punto crtico de fallo Si n trabajos >> n trabajadores reparto automtico de carga
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
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)
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) Reduce: T procesa valores asociados a una clave
P.ej. Palabras que aparecen en su parte de datos de entrada 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:
Inspirado en modelo Bulk Synchronous Parallel de Valiant Implementado como arquitectura maestro/trabajador
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 M reparte grafo entre T y controla sincronizacin de supersteps
Modelo de computacin Map-Reduce
Extrado de tutorial sobre MapReduce de Jerry Zhao y Jelena Pjesivac-Grbovic

Modelo de computacin Pregel
Pregel: A System for Large-Scale Graph Processing Grzegorz Malewicz et al.; SIGMOD 10
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
Modelo cliente/servidor
Arquitectura asimtrica: 2 roles en la interaccin
Cliente: Solicita servicio Servidor: Proporciona servicio
Activo: inicia interaccin
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
Esquema cliente/servidor
Interfaz de Servicio Peticin (args.)
Cliente
Respuesta
Servidor
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) Ejemplo:
nfasis en recursos: ops. CRUD (HTTP GET, PUT, DELETE, POST) AddBook(nb) vs. 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
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.

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
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
Esquema con proxy

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

Forward
Open
Reverse
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
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 P. ej. actualizar simultneamente dato replicado en varios servidores Mejora tolerancia a fallos pero no latencia y escalabilidad Esquema simtrico: Actualizar simultnea en todas las rplicas Esquema asimtrico: Actualizar en primario y propagar a secundarios
Si mltiples servidores deben cooperar para ofrecer servicio Necesidad de coherencia (sobrecarga para mantenerla):
Cliente/servidor con replicacin
C C C
p p
C S C C
p p
S S S
C C C
p
p p p
S S S
Cdigo mvil
Viaja el cdigo en vez de los datos y/o resultados Requiere:
Arquitecturas homogneas o Interpretacin de cdigo o Mquinas virtuales Cdigo por demanda (COD) Evaluacin remota (REV) Agentes mviles
Modelos alternativos
Servidor enva cdigo a cliente P.e. applets Cliente dispone de cdigo pero ejecucin debe usar recursos servidor P.ej. Cyber-Foraging Componente autnomo y activo que viaja por SD
Cdigo por demanda
Interfaz de Servicio Peticin
Cliente
Resp=Cdigo(args)
Cdigo
Servidor
Evaluacin remota
Interfaz de Servicio Peticin(args)+Cdigo
Cliente
Respuesta
Servidor
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
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 Cliente debe conocer direccin y puerto del Binder
Binder: mantiene correspondencias ID servicio (DMS, PS) 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

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 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 BG: ID [DMS] ; BL: ID [PS]
ID servicio = [DM+pto]
M1 C DM2 + ptoS 1
M2 DM2 + ptoS S
Info. de contacto
Direccin de servicio
ID servicio = [DM+idsrv]: Alta

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

M2 Idsrv ptoS M1 C DM2+idsrv 1 idsrv? ptoS 2 M2 DM2 + ptoS S Binder ptoB
DM2 + ptoB binder
Binder ptoB
ID servicio = [idsrv]; Slo BG: Alta

M3 Idsrv DM2 + ptoS M1 C idsrv binder DM3+ptoB 2 DM3 + ptoB binder
Idsrv DM2 + ptoS M2 1 DM2 + ptoS S binder DM3 +ptoB
ID servicio = [idsrv]; Slo BG: Consulta

M3 idsrv DM2 + ptoS M1 C idsrv 1 idsrv? DM2 + ptoS 2 M2 DM2 + ptoS S binder DM3 +ptoB
DM3 + ptoB binder
binder DM3+ptoB
ID servicio = [idsrv]; BG+BL: Alta

M1 C idsrv Idsrv ptoS 2 M2 DM2 + ptoL BL
BL ptoL | BG DM3+ptoB M3 Idsrv DM2 BG DM3 + ptoB 4 Idsrv DM2

Idsrv ptoS M2 1
DM2 + ptoS S
BL ptoL | BG DM3+ptoB
ID servicio = [idsrv]; BG+BL: Consulta

BL ptoL | BG DM3+ptoB C idsrv 1 DM2 3 M1 2 idsrv? ptoS M2 DM2 + ptoL BL Idsrv ptoS M2 DM2 + ptoS S BL ptoL | BG DM3+ptoB
idsrv? M3
BG DM3 + ptoB Idsrv DM2

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 (id. servicio + versin) puerto
Consulta a binder en dir. mquina
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
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
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
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 Ms tolerantes a fallos (ante rearranque del servidor) Reduce n de mensajes: no comienzos/finales de sesin. Ms econmicos para servidor (no consume memoria)
Peticiones autocontenidas.
Ventajas de servicio sin estado:
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)

Servicio de ficheros con estado: OPEN

C open(f,...) 3 x OPEN, f x f; inodo N S x N | pos 0
Servicio de ficheros con estado: READ

C read(3,b,t) 3 x READ, x, t DATOS, tl (ledo) f; inodo N S x N | ant+tl
Servicio de ficheros con estado: LSEEK

C lseek(3,m,p) 3 x LSEEK,x,m=SEEK_SET,p p f; inodo N S x N | pos p
Servicio de ficheros con estado: CLOSE

C close(3) 3 CLOSE, x OK f; inodo N x S -
Servicio de ficheros sin estado: OPEN

C open(f,...) 3 N | pos 0 BUSCAR, f N f; inodo N S
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 S
Servicio de ficheros sin estado: LSEEK

C lseek(3,m,p) 3 N | pos p S
f; inodo N
Servicio de ficheros sin estado: CLOSE

C close(3) 3 S
f; inodo N
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
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 PUT sustituye completamente contenido previo de recurso POST (no idempotente) permite actualizaciones parciales
Como parte de procesado puede crear/actualizar recurso
Leases
Mecanismo para mejorar tolerancia a fallos en SD Modo de operacin
Deteccin y tratamiento de cadas de clientes y servidores
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 Si cliente cae y no renueva el lease, recurso abandonado Si servidor cae, en reinicio obtiene renovaciones
Puede reconstruir los recursos Excepto por leases, cliente no tiene por qu contactar con servidor
Aplicacin tpica (genrica) de leases:
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)

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
Serv. cerrojos con estado: leases (1)

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


m1 C1 m2 C2 m3 libre
c1 lease(m1) cola de mensajes de S c2 lease(m2) S


cola de mensajes de S S

c1 lease(m1) c3 lock(m3) cola de mensajes de S c2 lease(m2) Treinicio>Tlease S


c3 lock(m3)
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
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
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)
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)
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 Se enva a subscriptores interesados en el mismo
Editor E (publisher) genera un evento
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 Alternativa, pull: suscriptor pregunta si hay notificaciones
Normalmente, push: suscriptor recibe notificaciones
Calidad de servicio (orden entrega o prdida de notificaciones) Posible uso de leases en suscripcin
Modelo editor/subscriptor
Su1 Su2 Su3 Su4
suscribe(ev5) notifica(ev5) suscribe(ev3) publica(ev5) suscribe(ev5) notifica(ev5) suscribe(ev1)
Ed1 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
Cliente/servidor vs. Editor/suscriptor

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

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

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 Y/O a colaboracin y comunicacin entre usuarios
Dedicados a compartir recursos (contenidos,UCP,almacn,...) Uso de red superpuesta (overlay): Red lgica sobre la fsica
Nodos de proceso como nodos de red Esquemas de encaminamiento y localizacin de recursos Difcil administracin y mayores problemas de seguridad
Desventajas de arquitectura P2P

Esquema Peer-to-Peer (P2P)
Entidad
Entidad Entidad
Entidad
Entidad Entidad Entidad
Entidad
Interfaz de Dilogo
Entidad
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 Posesin de recursos cambia segn sistema evoluciona
Corresponden a sistemas -voltiles con nodos ms cooperativos

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
Localizacin recursos en redes hbridas
A Survey of Peer-to-Peer Content Distribution Technologies S. Androutsellis-Theotokis y D. Spinellis; ACM Computing Surveys, 2004
Localizacin recursos en redes puras
A Survey of Peer-to-Peer Content Distribution Technologies S. Androutsellis-Theotokis y D. Spinellis; ACM Computing Surveys, 2004
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) Cada nodo slo necesita almacenar quin es su sucesor directo
NOTA: nodo almacena tambin predecesor
Localizacin de recurso: N busca K; algoritmo simple

Bsqueda lineal de sucesor a sucesor Hasta encontrar par de nodos a, b tal que ID (a, b] Ineficiente y no escalable O(N)
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
Bsqueda simple lineal
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)
Fingers en anillo 24
Wikipedia Chord
Bsqueda en anillo 24
Wikipedia Chord
Bsqueda con fingers
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
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) 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 Actualizacin de tabla de fingers si necesario
Operacin peridica en cada nodo stabilize:
Operacin peridica en cada nodo fix_fingers: Operacin peridica en cada nodo check_predecessor:
Comprueba si sigue vivo predecesor: No predecesor = NULO
Alta incluye transferencia de recursos asociados ahora a N

Alta de un nodo
Alta de un nodo: paso a paso
Np Nn
Ns
Np Nn
Ns
Np Nn
Ns
Np Nn
Ns
Estado inicial
join(Nn)
stabilize(Nn)
stabilize(Np)
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
Tablas finger despus de alta y baja

Si Stems Dis Tribu I Dps

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Si Stems Dis Tribu I Dps

Enviado por

Direitos autorais:

Formatos disponíveis

Sistemas Operativos Distribuidos

Arquitectura de los Sistemas Distribuidos

Arquitectura editor-subscriptor Arquitectura Peer-to-peer

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

Desacoplamiento temporal (menos frecuente)

Vidas de entidades que interaccionan no tienen que coincidir

Sistemas Operativos Distribuidos 4

Arquitecturas guiadas por geometra de los datos

MPI facilita uso mediante topologas virtuales (Cartesian y Graph)

Topologa Cartesian de MPI

Arquit. de computacin en Google

Pregel ( 20% de computaciones en Google)

Modelo de computacin Map-Reduce

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

Modelo de computacin Pregel

Arquitecturas en SD de propsito general

Sistemas Operativos Distribuidos 10

Fernando Prez Costoya

Pasivo: responde a peticin de servicio

Desventajas de arquitectura cliente/servidor

Alternativas en diseo de la interfaz de servicio

Sistemas Operativos Distribuidos 12

Cliente/servidor con cach

Necesidad de coherencia: sobrecarga para mantenerla

Puede posibilitar modo de operacin desconectado

Pre-fetching: puede mejorar latencia de operaciones pero

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.

Posibles repartos entre C y S

Qu labor se asigna a mquina cliente? (grosor creciente)

Sistemas Operativos Distribuidos 15

Cliente/servidor con proxy

Actan como tuberas

Sistemas Operativos Distribuidos 16

Fernando Prez Costoya

Esquema con proxy

Interfaz de Servicio 1 Peticin (args.)

Interfaz de Servicio 2 Respuesta

Wikipedia: Proxy server

Sistemas Operativos Distribuidos 18

Fernando Prez Costoya

Funcionalidad dividida en varios niveles (multi-tier)

Cada nivel puede implementarse como un servidor

Mltiples servidores idnticos cooperan en servicio

Sistemas Operativos Distribuidos 19

Fernando Prez Costoya

Cliente/servidor con replicacin

Sistemas Operativos Distribuidos 20

Cliente/servidor con replicacin

Sistemas Operativos Distribuidos 21

Fernando Prez Costoya

Sistemas Operativos Distribuidos 22

Cdigo por demanda

Interfaz de Servicio Peticin

Sistemas Operativos Distribuidos 23

Fernando Prez Costoya

Interfaz de Servicio Peticin(args)+Cdigo