SD Arquitectura 2021 Parte1

Sistemas Distribuidos
Arquitectura de
los Sistemas
Distribuidos
Índice
• Introducción
• Patrones de interacción
• Arquitecturas para computación distribuida
1ª parte
• Arquitectura cliente-servidor (incluida en
– Variaciones del modelo examen)
– Aspectos de diseño del modelo cliente/servidor
• Arquitectura editor-subscriptor
• Arquitectura productor-consumidor
• Arquitectura Peer-to-peer 2ª parte
– Sistemas P2P desestructurados (no incluida
• BlockChain, Napster, BitTorrent, Gnutella, Kazaa… en examen)
– Sistemas P2P estructurados (Protocolo Chord)
Sistemas Distribuidos Fernando Pérez Costoya
2
Retomando la definición de SD
• Plano físico (plataforma distribuida):
– Conjunto de nodos conectados por una red sin memoria compartida
• Plano lógico (aplicación o servicio distribuido):
– Conjunto de procesos que se comunican mediante paso de mensajes
Procesos (círculos) de distintas aplicaciones (colores),

potencialmente de diversos usuarios
3
Plataforma distribuida
• Conjunto de máquinas conectadas por una red

– “propias” (on premises) o “alquiladas” (cloud)
• Puede haber distintos grados de heterogeneidad
• Características de cada máquina:
– Tipo de procesador (x86, ARM…)
– Nº de UCPs
– Nº de GPUs
– Otros recursos hardware: memoria, dispositivos, red…
– S.O. instalado (por ejemplo, la versión 5.4 de Linux)
– Aplicaciones y bibliotecas de sistema instalados (p.ej., Ubuntu 20.04)
– Otras aplicaciones y bibliotecas instalada (p.e. Java versión )

4
Aplicación/servicio distribuidos
• Conjunto de procesos que se comunican por paso de mensajes

– Pueden ser multithread
– Algunos pueden comunicarse mediante memoria/fichero compartidos
 Deben ejecutar en la misma máquina
• Requisitos de cada proceso:
– Tipo de procesador
– Necesidades de recursos (cuotas de uso, valores máximos y mínimos)

5
Despliegue app en plataforma distribuida
• Conjunto de procesos que se comunican por paso de mensajes

– Pueden ser multithread
– Algunos pueden comunicarse mediante memoria/fichero compartidos
• Requisitos de cada proceso:
– Tipo de procesador
– Necesidades de recursos (cuotas de uso, valores máximos y mínimos)

6
Patrones de interacción en los SD
• Organización lógica de componentes de aplicación distribuida
– Qué roles ejercen los procesos y cómo se comunican entre sí
– Y cuál es su correspondencia con nodos de SD físico
– La “topología” de la aplicación distribuida
• En principio, tantos como aplicaciones
– Pero hay patrones que se repiten de forma habitual
• Patrones más frecuentes en SD de propósito general
– Cliente/servidor (C/S)
– Editor/subscriptor (EdSu); Publisher/Subscriber (PubSub)
– Productor/consumidor (ProdCons)
– Peer-to-peer (Paritaria)
• Computación distribuida (CD) presenta sus propios patrones
– Maestro/trabajador
– Arquitecturas guiadas por la “geometría” de los datos
7
Grado de acoplamiento
• Sea cual sea el patrón, conlleva interacción entre entidades
• Interacción tradicional implica acoplamiento espacial y temporal
• Desacoplamiento espacial (de referencia)
– Entidad inicia interacción no hace referencia directa a la otra entidad
• No necesitan conocerse entre sí
• Desacoplamiento temporal
– Vidas de entidades interaccionando no tienen que coincidir en tiempo
• 2 desacoplamientos son independientes entre sí
• Estos modos de operación “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.”

8
Ejemplo de grados de acoplamiento
espacial acoplado desacoplado

temporal
acoplado llamada telefónica retransmisión TV en directo
desacoplado carta postal anuncio en tablón
espacial acoplado desacoplado

temporal
acoplado C/S: sockets, RPC, RMI EdSu push | comun. Grupo
desacoplado no habitual m.comp | EdSu pull | ProdCons

9
Arquitecturas CD Maestro/Trabajador
• Trabajo: múltiples tareas que pueden ser de distinto tamaño
• Maestro M reparte tareas entre nodos trabajadores T
– Cuando T termina tarea, lo notifica a M, que le asigna otra
• Si nº tareas >> nº trabajadores  reparto automático de carga
– Reparto equilibrado ante tareas de distintos tamaños
– Reparto equilibrado ante nodos de distintas prestaciones
• Tolerancia a fallos:
– Caída de T (frecuente si SD grande y trabajo largo):
• M reasigna a otro trabajador la tarea no completada
• Pero esta tarea ya se ha ejecutado parcialmente
• Cuidado con los efectos colaterales (idempotencia)
– Caída de M (muy poco frecuente): Punto crítico de fallo
• Uso de múltiples maestros: Uso de replicación activa o pasiva
• 2ª práctica de grupo: implementar M/T con Java RMI
10
Maestro/trabajador
solicita ejecución asigna tarea

trabajador trabajador trabajador
de un trabajo
usuario maestro trabajador trabajador trabajador
fin de tarea trabajador trabajador trabajador
• Maestro planificador y gestor de recursos

• Si plataforma soporta múltiples aplicaciones, alternativas:
– 1 maestro por aplicación que negocia con un meta-maestro global
– 1 maestro global que gestiona todas las aplicaciones

11
Arquitecturas CD “geométricas”
• Arquitecturas guiadas por la “geometría” de los datos
– Matrices multidimensionales, grafos, etc.
– Condiciona la computación; Normalmente:
• Elementos cercanos de una matriz se procesan simultáneamente
• Vértices directamente conectados se procesan simultáneamente
• Distribución de datos y computación acorde con la geometría
– P.e. Matriz
• Cada nodo se encarga de sub-matriz
• Comunicación más frecuente con nodos “vecinos cartesianos”
– P.e. Grafo
• Cada nodo se encarga de un sub-grafo
• Comunicación siguiendo aristas
• Normalmente se complementa con Maestro/Trabajador
12
Ejemplos de herramientas que usan M/T
• MapReduce (Google; versión libre: Hadoop MapReduce)

– Procesamiento batch de datos masivos
– No adecuado para algoritmos iterativos ni procesamiento interactivo
• Pregel (Google; versión libre: Apache Giraph)
– Especializado en procesamiento de grafos (p.e. PageRank)
• Apache Spark: no tratado en esta presentación
– Almacenamiento de datos en memoria (resilient distributed datasets)
– Soporte algoritmos iterativos y procesamiento interactivo
• Tensorflow (Google): no tratado en esta presentación
– Herramienta para el aprendizaje automático
– Modelo de programación y ejecución de algoritmos de este tipo

13
Motivando MapReduce
• Escenario: log de accesos a páginas de sitio web enorme
– Log de gran tamaño distribuido en particiones por varios nodos
• Reto: cálculo de nº accesos únicos (≠ IP) a cada página
• Programación muy compleja
– Despliegue de procesos en nodos
– Cada proceso lee datos de log de una partición “cercana”
– Y extrae de cada entrada → (página, IP que la accede)
– Envíos de información de una página a mismo nodo (¿uso de hash?)
• Para que pueda detectar y descartar IPs repetidas
– Además, debe gestionar caídas de nodos
• Escenario similar en problemas afines
• ¿Posible automatización? → MapReduce (MR)
– Programador se ocupará solo de la funcionalidad específica
– No más eficiente que solución ad hoc pero mucho más productiva
14
Procesando log...
Partición1
PgA IP1 fecha… PgA IP1

PgB IP2 fecha… PgA IP2
PgA IP2 fecha… PgA IP1
PgA 2
PgB 3
PgB IP3 fecha… PgB IP2
PgB IP4 fecha… PgB IP3
PgA IP1 fecha… PgB IP4
Partición2
Map Reduce

15
MapReduce
• Maestro-trabajador con 2 tipos de tareas: Map y Reduce
• Programador solo codifica funciones map y reduce
– map: recibe dato de entrada y genera (clave, valor)
• En ejemplo recibe entrada de log → (página, IP que la accede)
– reduce: recibe y procesa valores asociados a clave
• En ej. calcula nº accesos únicos a una página → (página, nº accesos)
• MapReduce se encarga (entre otras labores) de:
– Establecer particiones y desplegar maestro y trabajadores
– Maestro asigna tareas Map y Reduce a trabajadores
– Tarea Map lee sus datos entrada y llama función map por cada dato
– Datos generados por función map se almacenan en disco local
• Clasificados por hash de clave en tantas regiones como tareas Reduce
– Tarea Reduce lee su región de cada tarea Map y
• Llama a función reduce con clave y valores asociados
– Tolerancia a fallos
16
Modelo de computación Map-Reduce
Más detalles
en Sistemas
Orientados a
Servicios
Extraído de tutorial sobre MapReduce de Jerry Zhao y Jelena Pjesivac-Grbovic

17
Pregel
• Modelo diseñado para procesar grafos de gran escala

• Computación organizada en “supersteps” síncronos:
– Cada vértice recibe datos de otros vértices por aristas de entrada
– Cambia su estado y genera datos por aristas de salida
• Incluso puede cambiar topología del grafo
• Inspirado en modelo “Bulk Synchronous Parallel” de Valiant
• Implementado como arquitectura maestro/trabajador
– M reparte grafo entre T y controla sincronización de “supersteps”
– M comunica a todos los T el inicio de un nuevo superstep
– Al inicio de superstep cada T procesa entradas de todos sus vértices
– Al final de superstep cada T envía datos de aristas de salida
• A los nodos T que gestionan los vértices destino involucrados
• Informa a M del final indicando cuántos de sus vértices están activos
– Se repite el ciclo hasta que todos los vértices están inactivos
18
Modelo de computación Pregel
vértice
inactivo
Pregel: A System for Large-Scale Graph Processing

Grzegorz Malewicz et al.; SIGMOD ‘10
19
M/T en Apache Spark y en TensorFlow
TensorFlow: Large-Scale Machine
Learning on Heterogeneous
Distributed Systems
Grafo de computación
Ejecución
Resilient Distributed Datasets: A Fault-Tolerant
Abstraction for In-Memory Cluster Computing

20
Arquitecturas en SD de propósito general
• Cliente/servidor (petición/respuesta); N clientes - 1 servidor
– Extensión del modelo proveedor/consumidor de servicio a SD
• Similar a biblioteca de servicio y programa que la usa pero en SD
– Interacción 1 cliente ↔ 1 servidor
• Editor/subscriptor; M editores – N subscriptores
– Extensión de esquema guiado por eventos a SD
– Interacción 1 editor → N subscriptores
• Productor/consumidor; M productores – N consumidores
– Extensión de esquema tipo tubería UNIX a SD
– Interacción 1 productor → 1 consumidor
– 1ª práctica individual: hay que diseñar un esquema de este tipo
• Peer-to-peer; N procesos
– Procesos cooperantes con el mismo rol
– Interacción N-N
21
Arquitecturas en SD de propósito general
C/S Ed/Su
C Ed Su
C S Ed Su
C Ed Su
Prod Cons P
Prod Cons P P
Prod Cons P
Prod/Cons P2P
22
Modelo cliente/servidor
• Arquitectura asimétrica: 2 roles interacción petición/respuesta
– Cliente: Solicita servicio
• Activo: inicia interacción
– Servidor: Proporciona servicio
• Pasivo: responde a petición de servicio
• Desventajas de arquitectura cliente/servidor
– Servidor “cuello de botella”  problemas de escalabilidad
– Servidor punto crítico de fallo
– Mal aprovechamiento de recursos de máquinas cliente
• Normalmente, acoplamiento espacial y temporal
• Servidor ofrece colección de servicios que cliente debe conocer
• Normalmente, petición especifica recurso, operación y args.
– NFS: READ, file_handle, offset, count
– HTTP: GET /index.html HTTP/1.1
23
Esquema cliente/servidor
Interfaz de Servicio
Petición (args.)
Cliente Respuesta Servidor
Resp=Código(args)
Alternativas en el diseño de interfaces cliente/servidor

• Interfaces específicos Más detalles en Sistemas
• Interfaces orientados a recursos (REST) Orientados a Servicios
1ª práctica individual: hay que diseñar una interfaz de servicio

24
Diseño de interfaces de servicio
• Interfaz específico de servicio: Solución más “natural”
– Se define un servicio para cada operación. Ejemplos:
• Un código numérico por cada operación. P.e. en DNS
www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-5
• Una palabra por operación. Ejemplo: en HTTP ops. HEAD, GET…
• Uso de lenguaje de marcado (XML, JSON). Ejemplo SOAP
• Interfaz orientado a recursos (REST)
– Mismas operaciones para todos servicios pero sobre distintos recursos
• Operaciones CRUD: Create|Read|Update|Delete
• Proyección sobre HTTP: PUT|GET|PUT|DELETE
• Ejemplo: servicio de venta de entradas a eventos:
– Específico: creaEv, eliminaEv, infoEv, ModEv, compraEntrEv…
– REST: PUT, DELETE, GET, PUT, PUT…
• Ventajas REST. Componente que no conoce detalles servicio:
– puede hacer caché, permitir solo lecturas, realizar registro log…
25
Reparto funcionalidad entre C y S
• ¿Qué parte del trabajo realiza el cliente y cuál el servidor?
• “Grosor del cliente”: Cantidad de trabajo que realiza
– Pesados (Thick/Fat/Rich Client) vs. Ligeros (Thin/Lean/Slim Client)
• Cierta OP se mueve del servidor al cliente (cliente + pesado)
• Ej. Javascript en navegador valida letra NIF en formulario
– Algunas peticiones pueden resolverse sin intervención del servidor
• Mayor autonomía del cliente y más ágil respuesta al usuario
• Mejor escalabilidad: Cliente gasta menos recursos de red y de servidor
– Otras no, pero procesamiento en servidor más rápido (no realiza OP)
• Mejor escalabilidad: Cliente gasta menos procesamiento de servidor
• aunque a veces se puede gastar más ancho de banda de red:
• Datos intercambiados pueden estar menos “procesados” (más volumen)
• Algunas ventajas de clientes ligeros
– Menos software: menos coste de mantenimiento y mejor seguridad
26
Posibles repartos entre C y S
• Arquitectura típica de aplicación basada en 3 capas:
– Presentación (interfaz de usuario gráfica: GUI)
– Aplicación: lógica de negocio
– Acceso a datos
• ¿Qué labor de la aplicación se le asigna a máquina cliente?
• Alternativas de “grosor” creciente:
– Nada: máquina cliente solo incluye servidor gráfico (p.e. X11 o VNC)
– Envía a app. eventos ratón/teclado y recibe de app. info. a dibujar en:
• Píxeles (VNC) o Primitivas gráficas (X11)
– solo GUI
– GUI + parte de la lógica de negocio
– GUI + lógica de negocio
– GUI + lógica de negocio + parte de lógica de acceso
27
Variaciones sobre el modelo C/S
• C/S con caché
• C/S con proxy
• C/S jerárquico
• C/S con reparto de carga
• C/S con alta disponibilidad
• C/S con código móvil

28
Cliente/servidor con caché
• Mejora latencia, reduce consumo red y recursos servidor
• Aumenta escalabilidad
– Mejor operación 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 operación desconectado
– Sistema de ficheros 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
• Se puede considerar caché como un tipo de replicación parcial
29
Cliente/servidor con proxy
• Componentes intermediarios entre cliente y servidor
• Interfaz de servicio de proxy debe ser igual que el del servidor:
– Proxy se comporta como cliente y servidor convencional
– Se pueden “enganchar” sucesivos proxies de forma transparente
• (Forward) Proxy
– Ubicado en la misma organización que los clientes
– Usuarios desconocen su existencia
– Uso: caché, punto único de salida a Internet…
• Reverse Proxy
– Ubicado en la misma organización que los servidores
– Usuarios especifican su dirección (desconocen existencia servidores)
– Uso: caché, punto único de entrada desde Internet, cortafuegos,
reparto de carga, distribución de servicios específicos…
30
Esquema con proxy
Petición (args.)
Cliente Respuesta Proxy
Interfaz de Servicio Petición

Respuesta
Servidor

31
Forward vs Reverse Proxy
https://www.quora.com/Whats-the-difference-between-a-reverse-proxy-and-forward-proxy
32
Cliente/servidor jerárquico
• Servidor actúa como cliente de otro servicio
– Igual que biblioteca usa servicio de otra biblioteca
• División vertical
• Funcionalidad dividida en varios niveles (multi-tier)
– P. ej. Aplicación típica con 3 capas:
• Presentación
• Aplicación: lógica de negocio
• Acceso a datos
– Cada nivel puede implementarse como un servidor
• División horizontal
– Múltiples servidores idénticos cooperan en servicio
• Similitud con P2P
– Traducir nombre de fichero en SFD o nombre de máquina con DNS
33
División horizontal
Espacios de nombres
Cliente montados
Servidores
idénticos

34
Cliente/servidor con reparto de carga
• Servidor único:
– Cuello de botella: afecta a latencia y ancho de banda
– Punto único de fallo: afecta a fiabilidad
• Mejorar prestaciones nodo servidor
– Escalado vertical (scale-up)
– Mejora rendimiento
– Pero no escalabilidad del servicio ni su tolerancia a fallos
• Uso de múltiples servidores (interacción M-N)
– Peticiones se reparten entre servidores
– Escalado horizontal (scale-out)
– Mejora latencia, escalabilidad del servicio y tolerancia a fallos
– Requiere esquema de reparto de carga
– Si servicio usa repositorio de datos, necesita replicación de datos
– ¿Qué ocurre si hay una partición de red que aísla réplicas?

35
Scale-up vs Scale-out
C C C S
p p p p p
C S C S C S
p
C C C S

36
Scale-out con datos replicados
C S d C S S d
C S d C S S d
C S d C S S d
En los propios nodos de servicio En servidores de almacenamiento

37
Teorema CAP (Eric Brewer)
• Un SD puede proporcionar las siguientes propiedades:
– Consistency:lectura dato siempre obtiene valor escritura más reciente
• Asume strong consistency (hay modelos consistencia menos exigentes)
– Availability: los datos están accesibles para todos los procesos
– Partition tolerance: comportamiento OK a pesar de particiones de red
• Teorema CAP: solo se pueden tener 2 de las 3 propiedades
• SD de tipo CP: Ante partición de red
• Asegura consistency pero no acceso a dato para todos (no Availability)
– Lecturas/escrituras sobre réplicas pueden devolver un error
• SD de tipo AP: Ante partición de red
• Asegura acceso a dato (Availability) pero no (strong) consistency
– Lectura puede obtener dato obsoleto
– Escritura modifica solo réplicas accesibles
• Al restablecerse red, necesaria reconciliación de cambios en cada partición
• ¿SD de tipo CA?: P irrenunciable: solo se puede elegir A o C
38
Latency vs. Consistency
• Teorema CAP solo aplicable cuando hay partición en la red
– Sin partición, SD puede ofrecer C y A simultáneamente
• ¿Es siempre deseable tener C en sistema sin particiones?
– Mantener consistencia estricta puede aumentar la latencia
– En ocasiones, puedo renunciar a C por conseguir mejor latencia (L)
• Aunque lectura pueda no obtener el valor de la última escritura
• Teorema PACELC (Abadi): extensión del teorema CAP
– PAC define el comportamiento cuando hay partición (= CAP)
– Sino (Else): LC especifica si se elige consistency o latency
• Posibles sistemas:
• PCEC: Siempre asegura consistency
• PAEC: solo asegura consistency si no hay partición
• PAEL: Nunca asegura consistency
• PCEL: solo asegura consistency si hay partición→ sin mucho sentido
39
Actualización de réplicas
– Consistency (C) depende de cómo se actualicen las réplicas
– Tres alternativas:
1. Replic. simétrica: Actualización simultánea de todas las réplicas
• Para C: asegurar escrituras de clientes se procesan en mismo orden
• Hay que secuenciar las operaciones de escritura
• Lo que provoca una sobrecarga → mala latencia (L)
2. Replicación con copia primaria/maestra y secundarias
• Por cada dato, una réplica es elegida como primaria/maestra
• Se actualiza copia primaria que lo propaga a secundarias
• Escritura síncrona: no se completa hasta total propagación
– No se procesan lecturas ni escrituras de ese dato hasta que termine
– Asegura C pero sacrificando L
• Escritura asíncrona: no se espera hasta total propagación
– Lecturas de copias secundarias pueden obtener valores obsoletos
– Asegura buena L pero sacrificando C
40
3. Uso de quorum (suponiendo N réplicas)

• Escritura simultánea síncrona en W réplicas
• Restantes réplicas se actualizarán asíncronamente
• Lectura síncrona de R réplicas
• Se elige el valor más actual (cada dato lleva asociado nº versión)
• Si R + W > N
• Lectura y escritura simultánea tienen al menos un nodo común
• No se puede leer un dato obsoleto
• Se asegura C pero sacrificando L por la necesidad de más sincronía
• Si R + W ≤ N
• Lectura y escritura simultánea pueden no tener ningún nodo en común
• Se puede leer un dato obsoleto
• Mejora L por menor nº de nodos involucrados, pero no se asegura C

41
R R R
C
C R C R R
C
R R R
Replicación simétrica Replicación primaria/secundarias Replicación con quorum: R y W=2

42
Cliente/servidor con alta disponibilidad
• Servicio con reparto de carga: cada servidor procesa 1 petición
– Si se cae, se pierde la petición en curso
• S. alta disponibilidad: debe completarse aunque caiga servidor
– Requiere uso de múltiples servidores replicados para cada servicio
• Soluciones alternativas (de mejor a peor t. de recuperación)
– Replicación activa (puede incluir también votación)
• Todos los servidores reciben y procesan la petición del cliente
• Requiere procesado determinista para que nodos tengan mismo estado
– Replicación pasiva: Primario procesa petición; Secundarios (standby)
• Hot standby: P envía estado a S; estado de S sincronizado con P
• Warm standby:
– P guarda estado en almacenamiento persistente replicado; P envía
periódicamente estado a S; estado de S no totalmente actualizado;
– caída P → S actualiza estado leyendo últimos cambios del almacenamiento
• Cold standby:
– S desactivado; P guarda estado en almacenamiento persistente replicado;
– caída P → Activa S y reconstruye estado leyendo todo el almacenamiento
43
Repl. activa vs. pasiva con hot standby
https://jaksa.wordpress.com/2009/05/01/active-and-passive-replication-in-distributed-systems/
44
Código móvil
• Viaja el código en vez de los datos y/o resultados
• Requiere:
– Arquitecturas homogéneas o
– Interpretación de código o
– Máquinas virtuales
• Modelos alternativos
– Código por demanda (COD)
• Servidor envía código a cliente
• P.e. applets
– Evaluación remota (REV)
• Cliente dispone de código pero ejecución debe usar recursos servidor
• P.ej. Cyber-Foraging
– Agentes móviles
• Componente autónomo y activo que viaja por SD

45
Código por demanda
Petición
Cliente Código Servidor
Resp=Código(args)

46
Evaluación remota
Petición(args)+Código
Cliente Servidor
Respuesta
Resp=Código(args)

47
Aspectos de diseño de cliente/servidor
Se van a considerar 5 aspectos específicos:
• Esquemas de servicio a múltiples clientes

• Gestión de conexiones
• Localización del servidor
• Servicio con estado o sin estado
• Comportamiento del servicio ante fallos

48
Servicio a múltiples clientes
• Servidor concurrente (p.e. servidor web Apache)
– Un flujo de ejecución atiende solo una petición en cada momento
– Se bloquea esperando datos de ese cliente y envía respuesta
• Servidor basado en eventos (p.e. servidor web Nginx)
– Un flujo de ejecución atiende múltiples peticiones simultáneamente
– Espera (y trata) evento asociado a cualquiera de las peticiones
– Implementación en UNIX de espera simultánea; alternativas:
• select/poll/epoll; uso de señales de t.real; operaciones asíncronas (aio)
– Para aprovechar paralelismo HW: un flujo de ejecución/procesador
• Servidor concurrente vs. basado en eventos:
• Peor escalabilidad (The C10K problem: http://kegel.com/c10k.html)
• Sobrecarga creación/destrucción/planificación de procesos/threads, más
cambios de contexto, más gasto de memoria (p.e. pilas de threads)…
• Pero programación menos “oscura”
• Why threads are a bad idea (for most purposes)?
• Why events are a bad idea (for high concurrency servers)?
49
Servidor concurrente: alternativas
• Threads (T) vs. Procesos (P)
– Generalmente threads: Más ligeros y comparten más recursos
– Pero más problemas de sincronización
• Creación dinámica de T/P según llegan peticiones
– Sobrecarga de creación y destrucción
• Conjunto (pool) de N T/P pre-arrancados:
– Al finalizar trabajo, en espera de más peticiones
– Poca carga  gasto innecesario
– Mucha carga  insuficientes
• Esquema híbrido con mínimo m y máximo M
– m pre-arrancados; m ≤ T/P ≤ M
– Si petición, ninguno libre y nº < M  se crea
– Si inactivo tiempo prefijado y nº > m  se destruye

50
Esquema servicio web secuencial
while (1)
acepta conexión
recibe petición
abre fichero
lee fichero
prepara cabecera
envía cabecera y fichero

51
Esquema concurrente dinámico
while (1)
acepta conexión
crea thread pasándole la conexión
thread
recibe petición
abre fichero
lee fichero
prepara cabecera

52
Esquema basado en eventos
Registra manejadores: nueva conexión, nuevos datos, fin lectura fichero

while (1)
espera próximo evento y lo trata Esquema usado por Nginx
Evento de nueva conexión
acepta conexión (crea un contexto asociado a la misma)
Evento de nuevos datos
recibe petición
abre y lee fichero asíncronamente
actualiza contexto para vincular lectura de fichero y conexión
Evento de fin de lectura de fichero
prepara cabecera
extrae del contexto la conexión asociada
envía cabecera y fichero asíncronamente

53
Esquema concurrente con pool
crea N threads
while (1)
acepta conexión
selecciona un thread y le asigna la conexión
thread
while (1)
espera asignación
recibe petición
abre fichero
lee fichero
prepara cabecera
Fernando Pérez Costoya
Esquema concurrente híbrido
crea N threads
Apache permite configurar esquema
while (1)
https://httpd.apache.org/docs/2.4/mpm.html
acepta conexión
si todos threads ocupados y no se ha llegado a umbral máximo
crea thread
selecciona un thread y le asigna la conexión
thread
while (1)
espera asignación o plazo de tiempo
si se cumple plazo y no se ha llegado a umbral mínimo
termina el thread
recibe petición
abre y lee fichero
prepara cabecera
Fernando Pérez Costoya
Gestión de conexiones
• En caso de que se use un esquema con conexión
• 1 conexión por cada petición
– 1 operación cliente-servidor
• conexión, envío de petición, recepción de respuesta, cierre de conexión
– Más sencillo pero mayor sobrecarga (¡9 mensajes con TCP!)
– Protocolos de transporte orientados a C/S (T/TCP, TCP Fast Open)
• Conexiones persistentes: N peticiones cliente misma conexión
– Más complejo pero menor sobrecarga
– Dado que servidor admite nº limitado de conexiones
– Dificulta reparto de servicio entre clientes
– Implica que servidor mantiene un estado
– Dificulta reparto de carga en esquema con escalado horizontal
– Posibilita el pipeline de las peticiones
• Enviar la siguiente petición sin esperar la respuesta de la previa
– Facilita server push
56
Evolución gestión de conexiones en HTTP
• Cliente accede a una página web:
o Debe de solicitar múltiples objetos al mismo servidor
• Todos los objetos inline en esa página
o Una media de 100 objetos por página (https://daniel.haxx.se/http2)
• HTTP/1.0
o Una conexión por cada petición
• HTTP/1.0 con keep-alive extension
o Conexiones persistentes
• HTTP/1.1
o Pipeline de peticiones
• HTTP 2
o Multiplexación de peticiones
57
Gestión de conexiones en HTTP/1.0
• Una conexión por cada objeto
• Connect | GET 1 | Resp 1 | Close | Connect | GET 2 | Resp 2 | Close | …
• Sobrecarga y latencia (round trip) de cada conexión
• Latencia (round trip) de cada petición
• ¿Cómo mejorar el rendimiento de la descarga en esta versión?
• Uso de conexiones simultáneas: objetos se piden en paralelo
• Connect | GET 1 | Resp 1 | Close
• ……………………………
• Connect | GET n | Resp n | Close
• Pero en tandas: nºmáx conexiones simultáneas/cliente limitado
• 2 en estándar original; actualmente navegadores suelen limitar a 6
• Connect | GET 1 | Resp 1 | Close | Connect | GET 2 | Resp 2 | Close | …
• ……………………………
• Connect |GET n| Resp n| Close | Connect | GET n+1| Resp n+1|Close|…
58
HTTP/1.0 con Keep-alive Extension
• Ante problemas de rendimiento de HTTP/1.0

• Extensión que permite a cliente mantener conexión activa
• Se usa una conexión para pedir todos los objetos de la página
• Connect | GET 1 | Resp 1 | GET 2 | Resp 2 | … | Close
• Se elimina sobrecarga y latencia de conexiones adicionales
• Se mantiene latencia de cada petición
• Uso combinado con conexiones simultáneas:
• Connect | GET 1 | Resp 1 | GET 2 | Resp 2 | … | Close
• ……………………………
• Connect | GET n | Resp n | GET n+1 | Resp n+1 | … | Close

59
Gestión de conexiones en HTTP/1.1
• Además de usar una conexión para pedir todos los objetos

• Se usa pipeline de peticiones
• Se envían todas las peticiones sin esperar su respuesta
• Connect | GET 1 | GET 2 | … | Resp 1 | Resp 2 | … | Close
• No hay latencia acumulada de peticiones
• Estándar exige que respuestas lleguen en orden de petición
• Orden FIFO → Problema de Head-of-line blocking
• Cada petición debe esperar a la anterior aunque sea mucho más larga
• ……………………………
• Connect | GET n | GET n+1 | … | Resp n | Resp n +1 | … | Close

60
Gestión de conexiones en HTTP/2
• Uso de multiplexing en vez de pipelining
• Elimina el problema de Head-of-line blocking
• Respuestas pueden llegar en cualquier orden
• Permite crear múltiples flujos dentro de cada conexión
• Cada paquete lleva un identificador de flujo único
• Paquetes de peticiones/respuestas se mezclan en misma conexión
• ……………………………
• Connect | GET n | GET n+1 | … | Resp n+1 | Resp n | … | Close

61
HTTP/2: multiplexación
https://www.nginx.com/blog/7-tips-for-faster-http2-performance/
62
Evolución de HTTP
https://kemptechnologies.com/solutions/http2/
63
Client Pull vs Server Push
• C/S: modo pull → cliente “extrae” datos del servidor
• Escenario: servidor dispone de información actualizada
• P.e. retransmisión web en modo texto de acontecimiento deportivo
• P.e. servicio de chat basado en servidor centralizado
• ¿Cómo recibe cliente actualizaciones? Alternativas:
• Cliente polling periódico al servidor (web: HTTP refresh; Ajax polling)
• Servidor responde inmediatamente, con nuevos datos si los hay
• Long Polling: Servidor no responde hasta que tenga datos
• Server Push: servidor “empuja” datos hacia el cliente
• Cliente mantiene conexión persistente y servidor envía actualizaciones
• Web: HTTP Server Push, Server-Sent Events, Web Sockets
• Usar editor/subscriptor en vez de cliente/servidor

64
Localización del servidor
• Servidor en máquina con dirección DM y usando puerto PS
– ¿Cómo lo localiza el cliente?  Binding
– Otro servidor proporciona esa información  problema huevo-gallina
• Binder mantiene correspondencias ID servicio  (DM, PS)
– Cliente debe conocer dirección y puerto del Binder
• Características deseables de ID de servicio:
– Ámbito global
– Mejor nombre de texto de carácter jerárquico (como pathname)
– Transparencia de ubicación
– Posible replicación: ID servicio  (DM1, PS1) | (DM2, PS2) ....
– Convivencia de múltiples versiones del servicio
• Suele estar englobado en un mecanismo más general
– Servicio de nombres (tema 5): Gestiona IDs de todos los recursos
65
Alternativas en la ID del servicio
1. Uso directo de dirección DM y puerto PS
– No proporciona transparencia
2. Nombre servicio + dir servidor (Java RMI Registry, Sun RPC)
– Servidor (binder) en cada nodo: nombre de servicio  puerto
– Impide migración del servidor
3. Nombre de servicio con ámbito global (DCE, CORBA, Mach)
– Servidor con ubicación conocida en el sistema
– Dos opciones:
a) solo binder global: nombre de servicio  [DM+PS]
b) Opción: binder global (BG) + binder local (BL) en puerto conocido
• BG: ID  [DM] ; BL: ID  [PS]
• Uso de caché en clientes para evitar repetir traducción
– Mecanismo para detectar que traducción en caché ya no es válida
66
Símil basado en “hechos reales”
• Suponiendo nº tfno persona = (nº tfno empresa + extensión)
• Quiero contactar con persona P (TP = TE + EP)
• Alternativas:
1. Conozco TP: lo uso
2. Conozco TE y extensión de información de la empresa
• Llamo a servicio información de la empresa y obtengo TP
3. (a) Conozco teléfono general de información de personas
• Llamo a servicio información general y obtengo TP
3. (b) Conozco tfno info. empresas y extensión info. de toda empresa
• Llamo a servicio información general de empresas y obtengo TE
• Llamo a servicio información de la empresa y obtengo TP

67
(1) ID servicio = [DM+pto]
M1 M2
1
C DM2 + ptoS DM2 + ptoS S
Info. de contacto Dirección de servicio

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

69
(2) ID servicio = [DM+idsrv]: Consulta
M2
Idsrv  ptoS
DM2 + ptoB binder
M1
¿idsrv?
1
C DM2+idsrv ptoS
M2
Binder  ptoB 2
DM2 + ptoS S
Binder  ptoB
70
(3a) ID servicio = [idsrv]; solo BG: Alta
M3
Idsrv  DM2 + ptoS
DM3 + ptoB binder
M1 2
C idsrv Idsrv  DM2 + ptoS
M2 1
binder DM3+ptoB
DM2 + ptoS S
binder DM3 +ptoB

71
(3a) ID servicio = [idsrv]; solo BG: Consulta
M3
idsrv DM2 + ptoS
DM3 + ptoB binder
M1
¿idsrv?
1
C idsrv DM2 + ptoS
M2
binder DM3+ptoB 2
DM2 + ptoS S
binder DM3 +ptoB

72
(3b) ID servicio = [idsrv]; BG+BL: Alta
M1 M2
Idsrv  ptoS
C idsrv DM2 + ptoL BL
2
BL  ptoL | BG DM3+ptoB

Idsrv  ptoS
M3 M2 1
Idsrv  DM2
BG DM3 + ptoB DM2 + ptoS S
3
4 Idsrv  DM2 BL  ptoL | BG DM3+ptoB
73
(3b) ID servicio = [idsrv]; BG+BL: Consulta
BL  ptoL | BG DM3+ptoB M2

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

74
Recapitulación del Binding
• Caso con BG y BL + versiones:
– Servidor:
• Elige puerto local
• Informa a binder local del alta:
– (id. servicio + versión) = puerto
• Informa a binder global del alta:
– (id. servicio + versión) = dir máquina
• Al terminar, notifica la baja a ambos binder :
– Ambos eliminan (id. servicio + versión)
– Cliente:
• Consulta a binder global
– (id. servicio + versión)  dir. máquina
• Consulta a binder en dir. máquina
– (id. servicio + versión)  puerto

75
Recapitulación (1): sin binding
89.107.176.80
miBanco
222
1
67.27.149.120
2 tiempoMad
cliente
333
3 tráficoMad
444
Info. conocida a priori

76
Recapitulación (2): binder local
89.107.176.80
binderLocal miBanco
1
alta(miBanco|222)
111 222
localhost:111
4
5 67.27.149.120
tiempoMad
cliente temp. Boadilla? 67.27.149.120:333
7 333
2
binderLocal tráficoMad
6
111 alta(tráficoMad|444) 444
localhost:111
Info. conocida a priori 3
Info. descubierta
77
Recapitulación (3a): binder global
89.107.176.80
miBanco
222
5
6.6.6.6 1
67.27.149.120
miBanco? 6.6.6.6:666 binderGlobal
4 tiempoMad
2
cliente 666
333
6
3
tráficoMad
7
444
Info. conocida a priori
Info. descubierta
78
Recapitulación (3b): binder local y global
saldo miCuenta? 89.107.176.80:222 89.107.176.80
9
binderLocal miBanco
1
alta(miBanco|222)
111 222
localhost:111
8
6.6.6.6 2
binderGlobal 67.27.149.120
alta(tiempoMad|67.27.149.120) 4 tiempoMad
cliente miBanco? 6.6.6.6:666 666 6.6.6.6:666
7 binderLocal 333
89.107.176.80 3
111
tráficoMad
5
444
Info. conocida a priori 6
Info. descubierta
79
Servicio con/sin estado
• ¿Servidor mantiene información de clientes?
• Ventajas de servicio con estado (aka con sesión remota):
– Mensajes de petición más cortos
– Mejor rendimiento (se mantiene información en memoria)
– Favorece optimización de servicio: estrategias predictivas
• Ventajas de servicio sin estado:
– Más tolerantes a fallos (ante rearranque del servidor)
• Peticiones autocontenidas
– Reduce nº de mensajes: no comienzos/finales de sesión.
– Más económicos para servidor (no consume memoria)
– Mejor reparto carga y fiabilidad en esquema con escalado horizontal
• Servicio sin estado base de propuesta REST Más detalles en
Sistemas Orientados
• Estado sobre servicios sin estado a Servicios
– Cliente almacena estado y lo envía al servidor (p.e. HTTP+cookies)
80
Servicio de ficheros con estado: OPEN
C S
open(“f”...)
x N | pos 0
OPEN, “f”
3 x
x
“f”; inodo N

81
Servicio de ficheros con estado: READ
C S
read(3,b,t)
x N | ant+tl
READ, x, t
3 x
DATOS, tl (leído)
“f”; inodo N

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

83
Servicio de ficheros con estado: CLOSE
C S
close(3)
x -
CLOSE, x
3 -
OK
“f”; inodo N

84
Servicio de ficheros sin estado: OPEN
C S
open(“f”...)
BUSCAR, “f”
3 N | pos 0
N
“f”; inodo N

85
Servicio de ficheros sin estado: READ
C S
read(3,b,t)
READ, N, ant, t
3 N | ant+tl
DATOS, tl (leído)
“f”; inodo N

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

87
Servicio de ficheros sin estado: CLOSE
C S
close(3)
3 -
“f”; inodo N

88
Leases
• Mecanismo para mejorar tolerancia a fallos en SD
– Detección y tratamiento de caídas de nodos
• Aplicación típica (genérica) de leases:
– Proceso A gestiona algún tipo de recurso vinculado con proceso B
• Proceso B no tiene por qué contactar de nuevo con A
– Si B cae, A no lo detecta y el recurso queda “abandonado”
• Modo de operación
– A otorga a B un lease que dura un plazo de tiempo
– B debe enviar a A mensaje de renovación lease antes de fin de plazo
– Si B cae y no renueva lease, se considera recurso “abandonado”
– Si A cae, en reinicio obtiene renovaciones
• Con suficiente información, puede “reconstruir” los recursos
• No confundir con un simple temporizador
– Proceso envía petición a otro y arranca temporizador
• Si se cumple antes de ACK, vuelve a enviar petición (≠ lease)
89
Aplicaciones de leases
• Aparecerán a menudo:
– Binding, caídas del cliente, suscripción en Ed/Su, caché de SFD, etc.
– Ejemplo: Aplicación a binding
• Binder asigna lease a servidor y servidor renueva lease
• Leases en servicios con estado
• Servicios inherentemente con estado: p.e. cerrojos distribuidos
• Uso de leases en servicio de cerrojos distribuido
– Servidor asigna lease a cliente mientras en posesión de cerrojo
– Clientes en posesión de cerrojos deben renovar su lease
– Rearranque de S: debe procesar primero peticiones de renovación
• Tiempo de reinicio de servicio > tiempo de renovación
– Reconstrucción automática de estado después de re-arranque de S
– Caída de cliente: falta de renovación
• Revocación automática de cerrojos de ese cliente
90
Serv. cerrojos con estado: leases (1)
C1 C2 C3
lock(m1) lock(m2) lock(m3)

.............. .............. ..............
unlock(m1) unlock(m2) unlock(m3)
c1  lock(m1) cola de mensajes de S

m1  libre c2  lease(m2)
m2  C2
m3  libre S
91
C1 C2 C3

.............. .............. ..............
c1  lease(m1) cola de mensajes de S

m1  C1 c2  lease(m2)
m2  C2
m3  libre S
92
C1 C2 C3

.............. .............. ..............
cola de mensajes de S
m1  C1
m2  C2
m3  libre S
93
C1 C2 C3

.............. .............. ..............
c1  lease(m1)
c2  lease(m2)
Ø Treinicio>Tlease S
94
C1 C2 C3

.............. .............. ..............

m1  C1
m2  C2
m3  libre S
95
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: Sería lo deseable
• Operaciones repetibles (idempotentes)
– Cuenta += cantidad (NO); Cuenta = cantidad (SÍ)
• Operación idempotente + al menos 1 vez ≈ exactamente 1
• Operaciones HTTP e idempotencia
– GET (sí); PUT (sí); POST (no); DELETE (sí)
• Tipos de fallos:
– Pérdida de petición o de respuesta (solo si comunicación no fiable)
– Caída del servidor
– Caída del cliente
96
Fallos con comunicación fiable
• Si cae servidor no siempre puede saber si ejecutado servicio
• Semántica de como mucho una vez
– Si llega respuesta, se ha ejecutado exactamente una vez
– Si no llega (servidor caído), se ha ejecutado 0 o 1 vez
• Para semántica al menos una vez (con ops. idempotentes)
– Retransmitir hasta respuesta (servidor se recupere) o fin de plazo
– Usar un sistema de transacciones distribuidas

97
Fallos con comunicación no fiable
• Pérdida de petición/respuesta
– Si no respuesta, retransmisión cuando se cumple plazo
– Nº de secuencia en mensaje de petición
– Si pérdida de petición, retransmisión no causa problemas
– Si pérdida de respuesta, retransmisión causa re-ejecución
• Si operación idempotente, no es erróneo pero gasta recursos
• Si no, es erróneo
– Se puede guardar histórico de respuestas (caché de respuestas):
• Si nº de secuencia duplicado, no se ejecuta pero manda respuesta
• Caída del servidor
– Si llega finalmente respuesta, semántica de al menos una vez
– Si no llega, no hay ninguna garantía (0 a N veces)

98
Caída del cliente
• Menos “traumática”: problema de computación huérfana
– Gasto de recursos inútil 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)
– En ocasiones puede ser mejor no abortar
99
Modelo editor/subscriptor
• Sistema de eventos distribuidos
• Suscriptor S (subscriber): interés por ciertos eventos (filtro)
• Editor E (publisher) genera un evento
– Se envía a subscriptores interesados en el mismo
• Paradigma asíncrono y desacoplado en espacio
– Editores y subscriptores no se conocen entre sí (≠ cliente/servidor)
• Normalmente, push: suscriptor recibe evento
– Alternativa, pull: suscriptor pregunta si hay eventos de interés
– Pull requiere que se almacenen eventos (+ complejo)
– Posibilita mecanismo desacoplado en el tiempo
• Facilita uso en sistemas heterogéneos
• Diversos aspectos relacionados con la calidad de servicio
– orden de entrega, fiabilidad, persistencia, prioridad, transacciones…
• Ejemplos: Mercado bursátil, subastas, chat, app domótica, etc.
100
Operaciones modelo editor/subscriptor
• Estructura típica del evento: [atrib1=val1; atrib2=val2; …]
– Un atributo puede ser el tema del evento
• suscribe(tipo) [S]: interés por cierto tipo de eventos
– Posible uso de leases en suscripción
– Subscriptor renueva lease
• baja(tipo) [S]: cese del interés
• publica(evento) [E]: generación de evento
• notifica(evento) [S]: envío de evento (esquema push)
• obtiene() [S]: lee siguiente(s) evento(s) (esquema pull)
– Puede ser bloqueante o no (si no hay eventos, respuesta inmediata)
• Extensión de modelo: creación dinámica de tipos de eventos
– anuncia(tipo) : se crea un nuevo tipo de evento
– baja_tipo(tipo): se elimina tipo de evento
– notifica_tipo(tipo) [S]: aviso de nuevo tipo de eventos
101
Modelo editor/subscriptor (push)
suscribe(tipo5)
Su1 notifica(ev5)
Ed1
suscribe(tipo3)
Su2
publica(ev5)
Ed2
suscribe(tipo5)
Su3 notifica(ev5)
Ed3
baja(tipo1)
Su4
Posible extensión: anuncio de nuevo tipo de evento (→S)

102
Modelo editor/subscriptor (pull)
suscribe(tipo5)
Su1 obtiene()
Ed1
suscribe(tipo3)
Su2
publica(ev5)
Ed2
suscribe(tipo5)
Su3 obtiene()
Ed3
baja(tipo1)
Su4
Posible extensión: anuncio de nuevo tipo de evento (→S)

103
Filtro de eventos por tema
• S se subscribe a tema y recibe notificaciones sobre el mismo
• Temas disponibles:
– Carácter estático: implícitamente conocidos
– Carácter dinámico: uso de operación de anuncio
• Ej. Creación de un nuevo valor en el mercado
• Organización del espacio de temas:
– Plano
– Jerárquico: (Ej. bolsas_europeas/españa/madrid)
– Uso de comodines en suscripción (Ej. bolsas_europeas/españa/*)
• Filtrados adicionales deben hacerse en aplicación
– Ej. Interesado en valores inmobiliarios de cualquier bolsa española
• Aplicación debe subscribirse a todas las bolsas españolas y
• descartar todos los eventos no inmobiliarios
104
Filtro de eventos por contenido
• Debe cumplirse condición sobre atributos del evento
– Extensión del esquema previo: tema es un atributo del evento
• Uso de lenguaje para expresión de la condición (≈ SQL)
• Filtrado de grano más fino y dinámico que usando temas
– Ej. Interés en valores inmobiliarios de cualquier bolsa española
• Menor consumo de ancho de banda
– Llegan menos datos a nodos subscriptor
• Simplifica app. subscriptora pero complica esquema Ed/Su
– Puede involucrar varios tipos de eventos de forma compleja
– Ejemplo (Tanenbaum):
– “Avísame cuando la habitación H420 esté desocupada más de 10
segundos estando la puerta abierta”

105
Cliente/servidor vs. Editor/suscriptor
Cl Ed
genera genera
datos datos
imprime almacena proyecta imprime almacena proyecta

datos datos datos datos datos datos
Se1 Se2 Se3 Su1 Su2 Su3
¿En cuál es más fácil añadir nuevo consumidor de datos?

¿Y si queremos que generador sepa cuándo ha procesado datos cada consumidor?

106
Implementaciones editor/suscriptor
• Comunicación directa
• No proporciona desacoplamiento espacial
• Uso de intermediario (broker)
• Desacoplamiento espacial pero cuello de botella y único punto de fallo
• Uso de red de intermediarios
– Distribución de eventos y aplicación de filtros “inteligente”
• Alternativa: uso comunicación de grupo

– Ed/Su basado en temas: tema = dirección de grupo

107
Implementación ed/su sin intermediario
Su1 Ed1
Su2
Ed2
Su3
Ed3
Su4
Contacto directo ed./ suscr.

 Acoplamiento espacial

108
Implementación ed/su con intermediario
Su1 Ed1
Su2
Int. Ed2
Su3
Ed3
Su4
Proceso intermediario
 Desacoplamiento espacial
 Cuello botella y punto fallo

109
Implementación ed/su con red interm.
Su1 Ed1
Int. Int.
Su2 Int.
Int. Int. Ed2
Su3 Int.
Int. Int. Ed3
Su4
Red de intermediarios
 Escalabilidad y fiabilidad
110
Implementación ed/su con c. grupo
Su1 Ed1
Su2
Ed2
Su3
Ed3
Su4
Comunicación de grupo

111
Modelo productor/consumidor
• Gestión de “almacenes” de mensajes
• Cada almacén tiene un nombre
• Productor Pr: envía (put) mensaje a un determinado almacén
• Consumidor Co solicita recibir mensaje de un almacén
– P
• Paradigma desacoplado en el espacio y en el tiempo
– Productores y consumidores no se conocen entre sí
• Diversos aspectos

112
suscribe(tipo5)
Pr1 obtiene()
Co1
put(al1, m)
Pr2
get(al1)
Co2
suscribe(tipo5)
Pr3 obtiene()
Co3
baja(tipo1)
Pr4

113
• Sistema de eventos distribuidos
• Suscriptor S (subscriber): interés por ciertos eventos (filtro)
• Editor E (publisher) genera un evento
– Se envía a subscriptores interesados en el mismo
• Paradigma asíncrono y desacoplado en espacio
– Editores y subscriptores no se conocen entre sí (≠ cliente/servidor)
• Normalmente, push: suscriptor recibe evento
– Alternativa, pull: suscriptor pregunta si hay eventos de interés
– Pull requiere que se almacenen eventos (+ complejo)
– Posibilita mecanismo desacoplado en el tiempo
• Facilita uso en sistemas heterogéneos
• Diversos aspectos relacionados con la calidad de servicio
• Ejemplos: Mercado bursátil, subastas, chat, app domótica, etc.
114
Recapitulación sobre leasing
Hemos visto distintos escenarios de uso:
• Binding
• Servidor de cerrojos
• Caída del cliente
• Editor/subscriptor

115
Leasing en el binding
consulta alta
Cliente Binder renovación Servidor

116
Leasing en servidor de cerrojos
lock lock
Cliente renovación Servidor renovación Cliente

117
Leasing para tratar caída del cliente
petición muy larga

Cliente renovación Servidor

118
Leasing en editor/subscriptor
publica subscribe
Editor Broker renovación Subscriptor

119

SD Arquitectura 2021 Parte1

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

SD Arquitectura 2021 Parte1

Cargado por

Copyright:

Formatos disponibles

Sistemas Distribuidos

Procesos (círculos) de distintas aplicaciones (colores),

• Conjunto de máquinas conectadas por una red

Sistemas Distribuidos Fernando Pérez Costoya

• Conjunto de procesos que se comunican por paso de mensajes

Sistemas Distribuidos Fernando Pérez Costoya

• Conjunto de procesos que se comunican por paso de mensajes

Sistemas Distribuidos Fernando Pérez Costoya

Sistemas Distribuidos Fernando Pérez Costoya

espacial acoplado desacoplado

espacial acoplado desacoplado

Sistemas Distribuidos Fernando Pérez Costoya

solicita ejecución asigna tarea

• Maestro planificador y gestor de recursos

Sistemas Distribuidos Fernando Pérez Costoya

• MapReduce (Google; versión libre: Hadoop MapReduce)

Sistemas Distribuidos Fernando Pérez Costoya

PgA IP1 fecha… PgA IP1

Sistemas Distribuidos Fernando Pérez Costoya

Extraído de tutorial sobre MapReduce de Jerry Zhao y Jelena Pjesivac-Grbovic

• Modelo diseñado para procesar grafos de gran escala

Pregel: A System for Large-Scale Graph Processing

Sistemas Distribuidos Fernando Pérez Costoya

Cliente Respuesta Servidor

Alternativas en el diseño de interfaces cliente/servidor

1ª práctica individual: hay que diseñar una interfaz de servicio

Sistemas Distribuidos Fernando Pérez Costoya

Cliente Respuesta Proxy

Interfaz de Servicio Petición

Sistemas Distribuidos Fernando Pérez Costoya

Sistemas Distribuidos Fernando Pérez Costoya

Sistemas Distribuidos Fernando Pérez Costoya

Sistemas Distribuidos Fernando Pérez Costoya

En los propios nodos de servicio En servidores de almacenamiento

Sistemas Distribuidos Fernando Pérez Costoya

3. Uso de quorum (suponiendo N réplicas)

Sistemas Distribuidos Fernando Pérez Costoya

Replicación simétrica Replicación primaria/secundarias Replicación con quorum: R y W=2

Sistemas Distribuidos Fernando Pérez Costoya

Sistemas Distribuidos Fernando Pérez Costoya

Cliente Código Servidor

Sistemas Distribuidos Fernando Pérez Costoya

Sistemas Distribuidos Fernando Pérez Costoya

• Esquemas de servicio a múltiples clientes

Sistemas Distribuidos Fernando Pérez Costoya

Sistemas Distribuidos Fernando Pérez Costoya

Sistemas Distribuidos Fernando Pérez Costoya

Sistemas Distribuidos Fernando Pérez Costoya

Registra manejadores: nueva conexión, nuevos datos, fin lectura fichero

Sistemas Distribuidos Fernando Pérez Costoya

• Ante problemas de rendimiento de HTTP/1.0

Sistemas Distribuidos Fernando Pérez Costoya

• Además de usar una conexión para pedir todos los objetos

Sistemas Distribuidos Fernando Pérez Costoya

Sistemas Distribuidos Fernando Pérez Costoya

Sistemas Distribuidos Fernando Pérez Costoya

Sistemas Distribuidos Fernando Pérez Costoya

Info. de contacto Dirección de servicio

Sistemas Distribuidos Fernando Pérez Costoya

Info. conocida Mensaje Info. binder Binder  ptoB

C idsrv Idsrv  DM2 + ptoS

binder DM3 +ptoB

binder DM3 +ptoB