Вы находитесь на странице: 1из 21

Sistemas Operativos Distribuidos

ndice

Sistemas Operativos Distribuidos

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

Sistemas Operativos Distribuidos


3

Fernando Prez Costoya

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.

Sistemas Operativos Distribuidos


4

Fernando Prez Costoya

Sistemas Operativos Distribuidos


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

Fernando Prez Costoya

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

Fernando Prez Costoya

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

Sistemas Operativos Distribuidos


7

2-Arquitecturas de SD

Fernando Prez Costoya

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


Sistemas Operativos Distribuidos
8

Fernando Prez Costoya

Sistemas Operativos Distribuidos


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

Fernando Prez Costoya

Modelo cliente/servidor

Sistemas Operativos Distribuidos


10

Fernando Prez Costoya

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

Sistemas Operativos Distribuidos


11

2-Arquitecturas de SD

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.

Fernando Prez Costoya

Servidor

Respuesta

Desventajas de arquitectura cliente/servidor

Sistemas Operativos Distribuidos


12

PUT /books/ISBN-8448130014 HTTP/1.1


Fernando Prez Costoya

Sistemas Operativos Distribuidos


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
Fernando Prez Costoya

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

2-Arquitecturas de SD

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


Sistemas Operativos Distribuidos
14

Fernando Prez Costoya

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:

Sistemas Operativos Distribuidos


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

Sistemas Operativos Distribuidos


13

Menor coste de operacin y mantenimiento


Mejor seguridad

Fernando Prez Costoya

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

Sistemas Operativos Distribuidos


16

Fernando Prez Costoya

Sistemas Operativos Distribuidos


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

Fernando Prez Costoya

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

2-Arquitecturas de SD

Fernando Prez Costoya

Cliente/servidor con replicacin

Servidor acta como cliente de otro servicio

Sistemas Operativos Distribuidos


19

Sistemas Operativos Distribuidos


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

Fernando Prez Costoya

Sistemas Operativos Distribuidos


20

Fernando Prez Costoya

Sistemas Operativos Distribuidos


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

Sistemas Operativos Distribuidos


21

Fernando Prez Costoya

Sistemas Operativos Distribuidos


22

Cdigo por demanda

Evaluacin remota

Interfaz de Servicio
Peticin

Cliente

Cdigo

Servidor

2-Arquitecturas de SD

Interfaz de Servicio
Peticin(args)+Cdigo

Cliente

Servidor
Respuesta

Resp=Cdigo(args)

Sistemas Operativos Distribuidos


23

Fernando Prez Costoya

Fernando Prez Costoya

Sistemas Operativos Distribuidos


24

Resp=Cdigo(args)

Fernando Prez Costoya

Sistemas Operativos Distribuidos


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

Sistemas Operativos Distribuidos


25

Fernando Prez Costoya

Sistemas Operativos Distribuidos


26

Alternativas en la ID del servicio

Fernando Prez Costoya

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

Sistemas Operativos Distribuidos


27

2-Arquitecturas de SD

Fernando Prez Costoya

Info. de contacto
Sistemas Operativos Distribuidos
28

Direccin de servicio
Fernando Prez Costoya

Sistemas Operativos Distribuidos


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

Sistemas Operativos Distribuidos


29

Fernando Prez Costoya

ID servicio = [idsrv]; Slo BG: Alta

Binder ptoB
Sistemas Operativos Distribuidos
30

Fernando Prez Costoya

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

2-Arquitecturas de SD

Fernando Prez Costoya

DM3 + ptoB binder

DM2 + ptoS
2

M2
DM2 + ptoS S
binder DM3 +ptoB

Sistemas Operativos Distribuidos


32

Fernando Prez Costoya

Sistemas Operativos Distribuidos


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

BL ptoL | BG DM3+ptoB

4 Idsrv DM2
Sistemas Operativos Distribuidos
33

Fernando Prez Costoya

Binding

ID servicio = [idsrv]; BG+BL: Consulta


BL ptoL | BG DM3+ptoB
C

idsrv?

idsrv?

M1

idsrv

M2

M3
BG DM3 + ptoB
Idsrv DM2
Sistemas Operativos Distribuidos
34

DM2 + ptoL BL
Idsrv ptoS

1
DM2

ptoS

M2
DM2 + ptoS S
BL ptoL | BG DM3+ptoB
Fernando Prez Costoya

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

2-Arquitecturas de SD

Fernando Prez Costoya

Sistemas Operativos Distribuidos


36

Fernando Prez Costoya

Sistemas Operativos Distribuidos


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

Sistemas Operativos Distribuidos


37

Gestin de conexiones

Adems, pipeline de peticiones

Implica que servidor mantiene un estado

Fernando Prez Costoya

Servicio con/sin estado

Sistemas Operativos Distribuidos


38

Fernando Prez Costoya

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)

Sistemas Operativos Distribuidos


39

2-Arquitecturas de SD

Fernando Prez Costoya

Sistemas Operativos Distribuidos


40

Fernando Prez Costoya

10

Sistemas Operativos Distribuidos


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

Sistemas Operativos Distribuidos


41

f; inodo N

Fernando Prez Costoya

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

Sistemas Operativos Distribuidos


43

2-Arquitecturas de SD

Fernando Prez Costoya

close(3)

Sistemas Operativos Distribuidos


42

Fernando Prez Costoya

f; inodo N

Sistemas Operativos Distribuidos


44

Fernando Prez Costoya

11

Sistemas Operativos Distribuidos


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

Sistemas Operativos Distribuidos


45

f; inodo N

Fernando Prez Costoya

Servicio de ficheros sin estado: CLOSE


C

close(3)
3

Sistemas Operativos Distribuidos


46

Fernando Prez Costoya

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

Sistemas Operativos Distribuidos


47

2-Arquitecturas de SD

Fernando Prez Costoya

Facilita integracin y despliegue independiente de componentes


Facilita incorporacin de tcnicas de caching o polticas de seguridad

Sistemas Operativos Distribuidos


48

Fernando Prez Costoya

12

Sistemas Operativos Distribuidos


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

Fernando Prez Costoya

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)

Sistemas Operativos Distribuidos


50

Fernando Prez Costoya

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

2-Arquitecturas de SD

Fernando Prez Costoya

c1 lock(m1) cola de mensajes de S


c2 lease(m2)

Sistemas Operativos Distribuidos


52

S
Fernando Prez Costoya

13

Sistemas Operativos Distribuidos


Serv. cerrojos con estado: leases (2)
C1

C2

C3

Serv. cerrojos con estado: leases (3)


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

Sistemas Operativos Distribuidos


53

Fernando Prez Costoya

Serv. cerrojos con estado: leases (4)


C1

C2

C3

cola de mensajes de S

m1 C1
m2 C2
m3 libre

Sistemas Operativos Distribuidos


54

Fernando Prez Costoya

Serv. cerrojos con estado: leases (5)


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

Sistemas Operativos Distribuidos


55

2-Arquitecturas de SD

Fernando Prez Costoya

m1 C1
m2 C2
m3 libre

c3 lock(m3)

Sistemas Operativos Distribuidos


56

cola de mensajes de S
S
Fernando Prez Costoya

14

Sistemas Operativos Distribuidos


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

Sistemas Operativos Distribuidos


57

Fernando Prez Costoya

Sistemas Operativos Distribuidos


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)

2-Arquitecturas de SD

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

Sistemas Operativos Distribuidos


59

Fernando Prez Costoya

Fernando Prez Costoya

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

Fernando Prez Costoya

15

Sistemas Operativos Distribuidos


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

Fernando Prez Costoya

Ejemplo editor/suscriptor

Sistemas Operativos Distribuidos


62

Fernando Prez Costoya

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?


Sistemas Operativos Distribuidos
63

2-Arquitecturas de SD

Fernando Prez Costoya

Sistemas Operativos Distribuidos


64

Fernando Prez Costoya

16

Sistemas Operativos Distribuidos


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

Sistemas Operativos Distribuidos


65

No hay cuellos de botella ni puntos crticos de fallo


Se aprovechan recursos de todas las mquinas

Fernando Prez Costoya

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

Sistemas Operativos Distribuidos


66

Fernando Prez Costoya

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

2-Arquitecturas de SD

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


Fernando Prez Costoya

Sistemas Operativos Distribuidos


68

Fernando Prez Costoya

17

Sistemas Operativos Distribuidos


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

Fernando Prez Costoya

Localizacin recursos en redes puras

Sistemas Operativos Distribuidos


70

Fernando Prez Costoya

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


Sistemas Operativos Distribuidos
71

2-Arquitecturas de SD

Fernando Prez Costoya

Sistemas Operativos Distribuidos


72

Fernando Prez Costoya

18

Sistemas Operativos Distribuidos


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

Bsqueda simple lineal

Chord: A Scalable Peer-to-peer Lookup Service for Internet Applications


Ion Stoica et al.; ACM SIGCOMM01

Fernando Prez Costoya

Bsqueda basada en fingers

Sistemas Operativos Distribuidos


74

Fernando Prez Costoya

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

2-Arquitecturas de SD

Fernando Prez Costoya

Sistemas Operativos Distribuidos


76

Fernando Prez Costoya

19

Sistemas Operativos Distribuidos


Bsqueda en anillo 24

Bsqueda con fingers

Chord: A Scalable Peer-to-peer Lookup Service for Internet Applications


Wikipedia Chord
Sistemas Operativos Distribuidos
77

Fernando Prez Costoya

Mantenimiento del anillo

Ion Stoica et al.; ACM SIGCOMM01


Sistemas Operativos Distribuidos
78

Fernando Prez Costoya

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


Sistemas Operativos Distribuidos
79

2-Arquitecturas de SD

Fernando Prez Costoya

Sistemas Operativos Distribuidos


80

Fernando Prez Costoya

20

Sistemas Operativos Distribuidos


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)

Chord: A Scalable Peer-to-peer Lookup Service for Internet Applications


Ion Stoica et al.; ACM SIGCOMM01
Sistemas Operativos Distribuidos
81

Fernando Prez Costoya

Baja de un nodo

Sistemas Operativos Distribuidos


82

Fernando Prez Costoya

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

Chord: A Scalable Peer-to-peer Lookup Service for Internet Applications


Ion Stoica et al.; ACM SIGCOMM01

Sistemas Operativos Distribuidos


83

2-Arquitecturas de SD

Fernando Prez Costoya

Sistemas Operativos Distribuidos


84

Fernando Prez Costoya

21