Arquitectura de los Sistemas Distribuidos

Please download to get full document.

View again

All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
 38
 
  Índice Arquitectura de los istemas Distribuidos Introducción Arquitecturas para computación distribuida Arquitecturas de computación en Google Modelo Map-Reduce y Pregel Arquitectura cliente- servidor
Related documents
Share
Transcript
Índice Arquitectura de los istemas 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 istemas P2P desestructurados istemas P2P estructurados Protocolo hord 2 3 Arquitecturas de los D Organización lógica de componentes de aplicación distribuida ómo es su patrón de interacción Qué roles ejercen los procesos involucrados Y cuál es su correspondencia con nodos de D 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 D de propósito general liente/servidor Editor/subscriptor Peer-to-peer (Paritaria) omputación distribuida (D) presenta sus propios patrones Maestro/trabajador Arquitecturas guiadas por la geometría de los datos 4 Grado de acoplamiento ea cual sea el modelo, 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 (menos frecuente) Vidas de entidades que interaccionan no tienen que coincidir Ej. Uso de memoria compartida 2 desacoplamientos son independientes entre sí Estos modos de 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. 2-Arquitecturas de D 1 5 Arquitecturas para D Maestro- trabajador M/T (aka maestro- esclavo) M va repartiendo trabajos entre nodos trabajadores T i nº trabajos nº trabajadores reparto automático de carga Tolerancia a fallos: aída de T: M reasigna sus trabajos pendientes ( efectos laterales!) aída de M: punto crítico de fallo Arquitecturas guiadas por geometría de los datos Matrices multidimensionales, grafos, etc. P.e. Matriz 2D ada nodo se encarga de sub-matriz omunicación más frecuente con nodos vecinos cartesianos MPI facilita uso mediante topologías virtuales (artesian y Graph) Permite localizar fácilmente vecinos Implementación puede optimizar asignación a plataforma 6 Topología artesian de MPI int MPI_art_create(MPI_omm comm, int ndims, int *dims, int *periods, int reorder, MPI_omm *comm_cart); int MPI_art_shift(MPI_omm comm_cart, int direction, int disp, int *rank_source, int *rank_dest); Using MPI William Gropp, Ewing Lusk y Anthony kjellum (MIT Press) Arquit. de computación en Google Modelo de computación Map-Reduce MapReduce 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 Modelo diseñado para procesar grafos de gran escala omputación organizada en supersteps síncronos: ada vértice recibe datos de otros vértices por aristas de entrada ambia su estado y genera datos por vértices de salida Incluso puede cambiar topología del grafo Inspirado en modelo Bulk ynchronous Parallel de Valiant Implementado como arquitectura maestro/trabajador M reparte grafo entre T y controla sincronización de supersteps 7 Extraído de tutorial sobre MapReduce de Jerry Zhao y Jelena Pjesivac-Grbovic 8 2-Arquitecturas de D 2 Modelo de computación Pregel Arquitecturas en D de propósito general liente- servidor Extensión del modelo proveedor/consumidor de servicio a D imilar a biblioteca de servicio y programa que la usa pero en D Interacción 1-N Editor/subscriptor Extensión de esquema guiado por eventos a D 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 Pregel: A ystem for Large-cale Graph Processing Grzegorz Malewicz et al.; IGMOD Modelo cliente/servidor Arquitectura asimétrica: 2 roles en la interacción liente: olicita servicio Activo: inicia interacción ervidor: Proporciona servicio Pasivo: responde a petición de servicio Desventajas de arquitectura cliente/servidor ervidor cuello de botella problemas de escalabilidad ervidor punto crítico de fallo Mal aprovechamiento de recursos de máquinas cliente Normalmente, acoplamiento espacial y temporal ervidor ofrece colección de servicios que cliente debe conocer Normalmente, petición especifica recurso, operación y args. NF: READ, file_handle, offset, count HTTP: GET /index.html HTTP/1.1 liente 12 Esquema cliente/servidor Interfaz de ervicio Petición (args.) Respuesta ervidor Resp=ódigo(args) Alternativas en diseño de la interfaz de servicio Operaciones específicas para cada servicio Énfasis en operaciones ( acciones ) Mismas ops. para todos servicios pero sobre distintos recursos (RET) Énfasis en recursos: ops. RUD (HTTP GET, PUT, DELETE, POT) Ejemplo: AddBook(nb) vs. PUT /books/ibn HTTP/1.1 2-Arquitecturas de D 3 liente/servidor con caché Mejora latencia, reduce consumo red y recursos servidor Aumenta escalabilidad Mejor operación en D La que no usa la red Necesidad de coherencia: sobrecarga para mantenerla Tolera el servicio que cliente use datos obsoletos? FD normalmente no; pero servidor de nombres puede que sí (DN) Puede posibilitar modo de operación desconectado ODA HTML5 Offline Web Applications Pre- fetching: puede mejorar latencia de operaciones pero i datos anticipados finalmente no requeridos: gasto innecesario Para arreglar la falacia 2 hemos estropeado la 3 Reparto funcionalidad entre y Qué parte del trabajo realiza el cliente y cuál el servidor? Grosor del cliente : antidad de trabajo que realiza Pesados (Thick/Fat/Rich lient) vs. Ligeros (Thin/Lean/lim lient) Ventajas de clientes ligeros Menor coste de operación y mantenimiento Mejor seguridad Ventajas de clientes pesados Mayor autonomía Mejor escalabilidad liente 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 Posibles repartos entre y 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 se asigna a máquina cliente? ( grosor creciente) Envía eventos de ratón/teclado y recibe info. a dibujar en forma de: Píxeles (VN) o Primitivas gráficas (X11) ambio de roles: servidor gráfico en máquina cliente 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 liente/servidor con proxy omponentes intermediarios entre cliente y servidor NOTA: Término corresponde también a un patrón de diseño Actúan como tuberías Pueden procesar/filtrar información y/o realizar labor de caché ímil con clases FilterInputtream FilterOutputtream de Java Diversos tipos: forward proxy, reverse proxy, gateways,... Mejor si interfaz de servicio uniforme: Proxy se comporta como cliente y servidor convencional e pueden enganchar sucesivos proxies de forma transparente Esta característica es una de las claves del éxito de la Web Arquitecturas de D 4 Esquema con proxy Wikipedia: Proxy server Mejor si Interfaz de ervicio 1 = Interfaz de ervicio 2 Forward Interfaz de ervicio 1 Petición (args.) liente Respuesta Proxy Open Interfaz de ervicio 2 Petición Respuesta ervidor Reverse liente/servidor jerárquico ervidor 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 ada nivel puede implementarse como un servidor División horizontal Múltiples servidores idénticos cooperan en servicio Traducir un nombre de fichero en FD Traducir de nombre de máquina a IP usando DN liente/servidor con replicación ervidor único: uello de botella: afecta a latencia y ancho de banda Punto único de fallo: afecta a fiabilidad Uso de múltiples servidores (interacción M- N) i sólo 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 i múltiples servidores deben cooperar para ofrecer servicio P. ej. actualizar simultáneamente dato replicado en varios servidores Mejora tolerancia a fallos pero no latencia y escalabilidad Necesidad de coherencia (sobrecarga para mantenerla): Esquema simétrico: Actualizar simultánea en todas las réplicas Esquema asimétrico: Actualizar en primario y propagar a secundarios Arquitecturas de D 5 liente/servidor con replicación ódigo móvil p p p p p p p p 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 ódigo por demanda (OD) ervidor envía código a cliente P.e. applets Evaluación remota (REV) liente dispone de código pero ejecución debe usar recursos servidor P.ej. yber-foraging Agentes móviles omponente autónomo y activo que viaja por D ódigo por demanda Evaluación remota Interfaz de ervicio Petición Interfaz de ervicio Petición(args)+ódigo liente ódigo ervidor liente ervidor Resp=ódigo(args) Respuesta Resp=ódigo(args) Arquitecturas de D 6 Aspectos de diseño de cliente/servidor Localización del servidor e van a considerar 5 aspectos específicos: Localización del servidor Esquemas de servicio a múltiples clientes Gestión de conexiones ervicio con estado o sin estado omportamiento del servicio ante fallos 25 ervidor en máquina con dirección DM y usando puerto P ómo lo localiza el cliente? Binding Otro servidor proporciona esa información problema huevo-gallina Binder: mantiene correspondencias ID servicio (DM, P) liente debe conocer dirección y puerto del Binder aracterí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, P1) (D, P2)... onvivencia de múltiples versiones del servicio uele estar englobado en un mecanismo más general ervicio de nombres (tema 5): Gestiona IDs de todos los recursos 26 Alternativas en la ID del servicio 1. Uso directo de dirección DM y puerto P No proporciona transparencia 2. Nombre servicio + dir servidor (Java RMI Registry, un RP) ervidor (binder) en cada nodo: nombre de servicio puerto Impide migración del servidor Nombre de servicio con ámbito global (DE, ORBA, Mach) ervidor con ubicación conocida en el sistema Dos opciones: 3. ólo binder global: nombre de servicio [DM+P] 4. Opción: binder global (BG) + binder local (BL) en puerto conocido BG: ID [DM] ; BL: ID [P] Uso de caché en clientes para evitar repetir traducción Mecanismo para detectar que traducción en caché ya no es válida ímil basado en hechos reales uponiendo nº tfno persona = (nº tfno empresa + extensión) Quiero contactar con persona P (TP = TE + EP) Alternativas: 1. onozco TP: lo uso 2. onozco TE y extensión de información de la empresa Llamo a servicio información de la empresa y obtengo TP 3. onozco teléfono general de información de personas Llamo a servicio información general y obtengo TP 4. onozco tfno gral 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 EP Arquitecturas de D 7 (1) ID servicio = [DM+pto] (2) ID servicio = [DM+idsrv]: Alta M1 D + pto 1 D + pto M1 D+idsrv Binder ptob 2 Idsrv pto 1 D + ptob binder Idsrv pto D + pto Info. de contacto Dirección de servicio Info. conocida Mensaje Info. binder Binder ptob (2) ID servicio = [DM+idsrv]: onsulta (3) ID servicio = [idsrv]; ólo BG: Alta M1 1 D+idsrv Binder ptob Idsrv pto idsrv? pto 2 D + ptob D + pto binder Idsrv D + pto M1 2 idsrv binder DM3+ptoB M3 DM3 + ptob Idsrv D + pto 1 D + pto binder Binder ptob binder DM3 +ptob Arquitecturas de D 8 (3) ID servicio = [idsrv]; ólo BG: onsulta (4) ID servicio = [idsrv]; BG+BL: Alta M1 idsrv 33 1 binder DM3+ptoB idsrv D + pto idsrv? D + pto 2 M3 DM3 + ptob D + pto binder binder DM3 +ptob M1 idsrv BL ptol BG DM3+ptoB BG 4 M3 DM3 + ptob Idsrv D 34 Idsrv pto 2 Idsrv D 3 D + ptol Idsrv pto 1 D + pto BL BL ptol BG DM3+ptoB (4) ID servicio = [idsrv]; BG+BL: onsulta Recapitulación del Binding BL ptol BG DM3+ptoB BG idsrv idsrv? M3 1 D DM3 + ptob Idsrv D 35 M1 2 3 idsrv? pto D + ptol Idsrv pto D + pto BL BL ptol BG DM3+ptoB aso con BG y BL + versiones: ervidor: 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) liente: onsulta a binder global (id. servicio + versión) dir. máquina onsulta a binder en dir. máquina (id. servicio + versión) puerto 36 2-Arquitecturas de D 9 ervicio a múltiples clientes ervidor secuencial Único flujo de ejecución atiende múltiples peticiones Operaciones asíncronas y/o espera por múltiples eventos (select/poll) Uso de máquina de estados para seguimiento de clientes olución compleja y que no aprovecha paralelismo HW ervidor concurrente olución más natural y que aprovecha paralelismo HW Threads (T) vs. Procesos (P) Generalmente threads: Más ligeros y comparten más recursos ervicio concurrente: alternativas reación dinámica de T/P según llegan peticiones obrecarga onjunto de N T/Ppre- 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 i petición, ninguno libre y nº M se crea i inactivo tiempo prefijado y nº m se destruye Gestión de conexiones Evolución de HTTP 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 TP!) Propuestas de protocolos de transporte orientados a / (T/TP) Varias peticiones de cliente usan misma conexión Más complejo pero menor sobrecarga Esquema usado en HTTP/1.1 (además, pipeline de peticiones) Dado que servidor admite nº limitado de conexiones Dificulta reparto de servicio entre clientes Implica que servidor mantiene un estado liente necesita pedir varios objetos al mismo servidor HTTP/1.0 onnect GET Resp lose onnect GET Resp lose obrecarga conexiones + latencia de conexiones y peticiones HTTP/1.0 + conexiones persistentes onnect GET Resp GET Resp lose Latencia de peticiones HTTP/1.1 (conexiones persistentes + pipeline de peticiones) onnect GET GET Resp Resp lose No latencia acumulada ervicio paralelo de peticiones aunque respuestas deben llegar en orden Arquitecturas de D 10 HTTP: conexiones simultáneas Paralelismo también mediante conexiones simultáneas HTTP/1.0 onnect GET Resp lose onnect GET Resp lose HTTP/1.0 + conexiones persistentes onnect GET Resp GET Resp lose onnect GET Resp GET Resp lose HTTP/1.1 (conexiones persistentes + pipeline de peticiones) onnect GET GET Resp Resp lose onnect GET GET Resp Resp lose ervicio con/sin estado ervidor 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) ervicio sin estado base de la propuesta RET e estudia en detalle en asignatura istemas Orientados a ervicios Estado sobre servicios sin estado liente almacena estado y lo envía al servidor (p.e. HTTP+cookies) ervicio de ficheros con estado: OPEN ervicio de ficheros con estado: READ open( f,...) 3 x OPEN, f x x N pos 0 read(3,b,t) 3 x READ, x, t DATO, tl (leído) x N ant+tl f ; inodo N f ; inodo N Arquitecturas de D 11 ervicio de ficheros con estado: LEEK ervicio de ficheros con estado: LOE lseek(3,m,p) 3 x LEEK,x,m=EEK_ET,p p x N pos p close(3) 3 - LOE, x OK x - f ; inodo N f ; inodo N ervicio de ficheros sin estado: OPEN ervicio de ficheros sin estado: READ open( f,...) read(3,b,t) 3 N pos 0 BUAR, f N 3 N ant+tl READ, N, ant, t DATO, tl (leído) f ; inodo N f ; inodo N Arquitecturas de D 12 ervicio de ficheros sin estado: LEEK ervicio de ficheros sin estado: LOE lseek(3,m,p) close(3) 3 N pos p 3 - f ; inodo N f ; inodo N Leases Mecanismo para mejorar tolerancia a fallos en D Detección y tratamiento de caídas de clientes y servidores Modo de operación ervidor otorga a cliente un lease que dura un plazo de tiempo liente debe renovar lease antes de fin de plazo Aplicación típica (genérica) de leases: ervidor gestiona algún tipo de recurso vinculado con un cliente Excepto por leases, cliente no tiene por qué contactar con servidor i cliente cae y no renueva lease, se detecta recurso abandonado i servidor cae, en reinicio obtiene renovaciones Puede reconstruir los recursos No confundir con un simple temporizador liente envía petición a servidor y arranca temporizador i se cumple antes de AK, vuelve a enviar petición ( lease) Aplicaciones de leases Aparecerán a menudo: Binding, caídas del cliente, suscripción en E/, caché de FD, etc. Leases en servicios con estado Algunos servicios son inherentemente con estado P. ej. cerrojos distribuidos Uso de leases en servicio de cerrojos distribuido ervidor asigna lease a cliente mientras en posesión de cerrojo lientes en posesión de cerrojos deben renovar su lease Rearranque de : 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 rearranque de aída de cliente: falta de renovación Revocación automática de cerrojos de ese cliente Arquitecturas de D 13 erv. cerrojos con estado: leases (1) erv. cerrojos con estado: leases (2) 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 libre m2 2 m3 libre c1 lock(m1) c2 lease(m2) cola de mensajes de m1 1 m2 2 m3 libre c1 lease(m1) c2 lease(m2) cola de mensajes de erv. cerrojos con estado: leases (3) erv. cerrojos con estado: leases (4) 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 1 m2 2 m3 libre cola de mensajes de Ø c1 lease(m1) c3 lock(m3) cola de mensajes de c2 lease(m2) Treinicio Tlease Arquitecturas de D 14 erv. cerrojos con estado: leases (5) 1 lock(m1) unlock(m1) m1 1 m2 2 m3 libre 57 2 lock(m2) unlock(m2) c3 lock(m3) 3 lock(m3) unlock(m3) cola de mensajes de omportamiento del servicio ante fallos Qué se garantiza con respecto al servicio ante fallos? Nada: ervicio puede ejecutar 0 a N veces Al menos una vez (1 a N veces) omo mucho una vez (0 ó 1 vez) Exactamente una vez: ería lo deseable Operaciones repetibles (idempotentes) uenta += cantidad (NO) uenta = cantidad (Í) Operación idempotente + al menos 1 vez exactamente 1 Tipos de fallos: Pérdida de petición o de respuesta (sólo si comunicación no fiable) aída del servidor aída del cliente 58 Fallos con comunicación fiable i cae servidor no siempre puede saber si ejecutado servicio emántica de como mucho una vez i llega respuesta, se ha ejecutado exactamente una vez i no llega (servidor caído), se ha ejecutado 0 ó 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 Fallos con comunicación no fiable Pérdida de petición/respuesta i no respuesta, retransmisión cuando se cumple plazo Nº de secuencia en mensaje de petición i pérdida de petición, retran
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks