PDF de programación - 2 Arquitectura de los Sistemas Distribuidos - Sistemas Distribuidos

Sistemas Distribuidos

Fernando Pérez Costoya

Índice

Sistemas Distribuidos

Arquitectura de
los Sistemas
Distribuidos

Introducción

•
• Arquitecturas para computación distribuida

– Arquitecturas de computación en Google

• Modelo Map-Reduce y Pregel
• Arquitectura cliente-servidor

– Variaciones del modelo
– Aspectos de diseño del modelo cliente/servidor

• Arquitectura editor-subscriptor
• Arquitectura Peer-to-peer

– Sistemas P2P desestructurados
– Sistemas P2P estructurados

• Protocolo Chord

Sistemas Distribuidos
2

Fernando Pérez Costoya

Arquitectura de los SD

Grado de acoplamiento

• Organización lógica de componentes de aplicación distribuida

– Cómo es su patrón de interacción
– Qué roles ejercen los procesos involucrados
– Y cuál es su correspondencia con nodos de SD físico
– “Topología” de la aplicación distribuida

• En principio, tantas como aplicaciones

– Pero hay patrones que se repiten de forma habitual

• Arquitecturas más frecuentes en SD de propósito general

– Cliente/servidor
– Editor/subscriptor
– Peer-to-peer (Paritaria)

• Computación distribuida (CD) presenta sus propios patrones

– Maestro/trabajador
– Arquitecturas guiadas por la “geometría” de los datos

• Sea cual sea el modelo, conlleva interacción entre entidades
•
• Desacoplamiento espacial (de referencia)

Interacción tradicional implica acoplamiento espacial y temporal

– Entidad inicia interacción 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. de ambos desacoplamientos: memoria compartida
• 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.”

Sistemas Distribuidos
3

Fernando Pérez Costoya

Sistemas Distribuidos
4

Fernando Pérez Costoya

2-Arquitectura de SD

1

Sistemas Distribuidos

Fernando Pérez Costoya

Arquitecturas para CD

Arquit. de computación en Google

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

– M va repartiendo trabajos entre nodos trabajadores T

• Si nº trabajos >> nº trabajadores  reparto automático de carga

– Tolerancia a fallos:

• Caída de T: M reasigna sus trabajos pendientes (¡efectos laterales!)
• Caída de M: punto crítico de fallo

• Arquitecturas guiadas por “geometría” de los datos

– Matrices multidimensionales, grafos, etc.
– P.e. Matriz 2D

• 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

• MapReduce

– 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 determinada clave

• P.ej. Extrae de logs web → (página, usuario que la accede)

• P.ej. Calcula nº accesos únicos a cada página → (página, nº accesos)

• 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 vértices 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”

Sistemas Distribuidos
5

Fernando Pérez Costoya

Sistemas Distribuidos
6

Fernando Pérez Costoya

Modelo de computación Map-Reduce

Modelo de computación Pregel

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

Fernando Pérez Costoya

Sistemas Distribuidos
8

Pregel: A System for Large-Scale Graph Processing
Grzegorz Malewicz et al.; SIGMOD ‘10

Fernando Pérez Costoya

2-Arquitectura de SD

2

Sistemas Distribuidos

Fernando Pérez Costoya

Arquitecturas en SD de propósito general

Modelo cliente/servidor

– Extensión del modelo proveedor/consumidor de servicio a SD
• Similar a biblioteca de servicio y programa que la usa pero en SD

• Cliente-servidor

– Interacción 1-N
• Editor/subscriptor

– Extensión de esquema guiado por eventos a SD
– Facilita el desacoplamiento espacial y, potencialmente, el temporal
– Interacción M-N

• Peer-to-peer

– Procesos cooperantes con el mismo rol
– Interacción N-N

• Arquitectura asimétrica: 2 roles en la interacción

– 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

Sistemas Distribuidos
9

Fernando Pérez Costoya

Sistemas Distribuidos
10

Fernando Pérez Costoya

Esquema cliente/servidor

Reparto funcionalidad entre C y S

Interfaz de Servicio

Cliente

Petición (args.)

Respuesta

Servidor

Resp=Código(args)

• Alternativas en diseño de la interfaz de servicio

• Énfasis en operaciones (“acciones”)

– Operaciones específicas para cada servicio
– 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

• ¿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)

• Ventajas de clientes ligeros

– Menor coste de operación y mantenimiento
– Mejor seguridad

• Ventajas de clientes pesados

– Mayor autonomía
– Mejor escalabilidad

• Cliente gasta menos recursos de red y de servidor

– Más ágil en respuesta al usuario

• Ej. “inteligencia en cliente”: Javascript valida letra NIF en form.

Sistemas Distribuidos
11

Fernando Pérez Costoya

Sistemas Distribuidos
12

Fernando Pérez Costoya

2-Arquitectura de SD

3

Sistemas Distribuidos

Fernando Pérez Costoya

Posibles repartos entre C y S

Cliente/servidor con caché

• 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 sólo 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)

– Sólo 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

• 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

– 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

Sistemas Distribuidos
13

Fernando Pérez Costoya

Sistemas Distribuidos
14

Fernando Pérez Costoya

Cliente/servidor con proxy

Esquema con proxy

• Componentes intermediarios entre cliente y servidor
• Actúan como “tuberías”

– Pueden procesar/filtrar información y/o realizar labor de caché
• Símil con clases FilterInputStream|FilterOutputStreamde Java

• Diversos tipos: forward proxy, reverse proxy, gateways, ...
•

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
– Esta característica es una de las claves del éxito de la Web

Cliente

Interfaz de Servicio

Petición (args.)

Respuesta

Proxy

Interfaz de Servicio

Respuesta

Petición

Servidor

Sistemas Distribuidos
15

Fernando Pérez Costoya

Sistemas Distribuidos
16

Fernando Pérez Costoya

2-Arquitectura de SD

4

Sistemas Distribuidos

Fernando Pérez Costoya

Wikipedia: Proxy server

Cliente/servidor jerárquico

Forward

Open

Reverse

• 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
– Traducir un nombre de fichero en SFD
– Traducir de nombre de máquina a IP usando DNS

Sistemas Distribuidos
17

Fernando Pérez Costoya

Sistemas Distribuidos
18

Fernando Pérez Costoya

Esquema multi-servidor

Scale-up vs Scale-out

• 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 ni tolerancia a fallos

• Uso de múltiples servidores (interacción M-N)
– Escalado horizontal (scale-out)
– Mejora latencia, escalabilidad y tolerancia a fallos
– Requiere esquema de reparto de carga

• Si servicio requiere datos replicados (p.e. DNS, Google FS)
– Necesidad (y sobrecarga) de mantener coherencia entre las réplicas
– Esquema simétrico: Actualización simu