Publicado el 17 de Febrero del 2019
985 visualizaciones desde el 17 de Febrero del 2019
2,2 MB
17 paginas
Creado hace 9a (11/02/2016)
Sistemas Distribuidos
Fernando Pérez Costoya
Índice
Arquitectura de los SD
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
• 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
Sistemas Distribuidos
2
Fernando Pérez Costoya
Sistemas Distribuidos
3
Fernando Pérez Costoya
Grado de acoplamiento
Arquitecturas para CD
Arquit. de computación en Google
• 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.”
• 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
4
Fernando Pérez Costoya
Sistemas Distribuidos
5
Fernando Pérez Costoya
Sistemas Distribuidos
6
Fernando Pérez Costoya
2-Arquitectura de SD
1
Sistemas Distribuidos
Fernando Pérez Costoya
Modelo de computación Map-Reduce
Modelo de computación Pregel
Arquitecturas en SD de propósito general
– 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
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
Sistemas Distribuidos
9
Fernando Pérez Costoya
Modelo cliente/servidor
Esquema cliente/servidor
Reparto funcionalidad entre C y S
• Arquitectura asimétrica: 2 roles en la interacción
– Cliente: Solicita servicio
– Servidor: Proporciona servicio
• Activo: inicia interacción
• 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
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
10
Fernando Pérez Costoya
Sistemas Distribuidos
11
Fernando Pérez Costoya
Sistemas Distribuidos
12
Fernando Pérez Costoya
2-Arquitectura de SD
2
Sistemas Distribuidos
Fernando Pérez Costoya
Posibles repartos entre C y S
Cliente/servidor con caché
Cliente/servidor con proxy
• 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
• 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|FilterOutputStream de 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
Sistemas Distribuidos
13
Fernando Pérez Costoya
Sistemas Distribuidos
14
Fernando Pérez Costoya
Sistemas Distribuidos
15
Fernando Pérez Costoya
Esquema con proxy
Wikipedia: Proxy server
Cliente/servidor jerárquico
Cliente
Interfaz de Servicio
Petición (args.)
Respuesta
Proxy
Interfaz de Servicio
Respuesta
Petición
Servidor
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
16
Fernando Pérez Costoya
Sistemas Distribuidos
17
Fernando Pérez Costoya
Sistemas Distribuidos
18
Fernando Pérez Costoya
2-Arquitectura de SD
3
Sistemas Distribuidos
Fernando Pérez Costoya
Esquema multi-servidor
Scale-up vs Scale-out
Código móvil
• 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 simultánea en todas las réplicas
– Esquema asimétrico: Actu
Comentarios de: 2 Arquitectura de los Sistemas Distribuidos - Sistemas Distribuidos (0)
No hay comentarios