La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

Sistemas Distribuidos I Conceptos de Sistemas Distribuidos y Arquitectura.

Presentaciones similares


Presentación del tema: "Sistemas Distribuidos I Conceptos de Sistemas Distribuidos y Arquitectura."— Transcripción de la presentación:

1 Sistemas Distribuidos I Conceptos de Sistemas Distribuidos y Arquitectura

2 Objetivos El objetivo general del diseño de un sistema distribuido no es muy diferente de otro sistema operativo. Eficiencia, Flexibilidad, Consistencia y Robustez Las diferencias se resumen en que los recursos están distribuidos, el overhead de la comunicación no puede ser despreciada y la alta probabilidad de fallas de los componentes

3 Objetivos Eficiencia – Es mas complejo por la existencia de los retardos en la comunicación. – Las primitivas usadas para comunicación a nivel del lenguaje o sistema operativo deben ser eficientes. – Buenos protocolos de comunicación a nivel de red. – Se deben tener en cuenta problemas de distribución de la carga, cuellos de botella o congestionamientos.

4 Objetivos Flexibilidad – Desde el punto de vista del usuario la amabilidad y libertad para usar el sistema. Amabilidad: capacidad de mapear problemas reales a problemas computacionales. Libertad: Permitirle al usuario decidir cuando, como y donde usar el sistema sin restricciones irracionales.

5 Objetivos Flexibilidad – Desde el punto de vista del sistema: Capacidad de evolucionar y migrar. Modularidad, Escalabilidad, portabilidad y interoperabilidad.

6 Objetivos Consistencia – Desde el punto de vista del usuario un sistema es consistente si existe uniformidad en el uso del sistema y el comportamiento es predecible. – La falta de información global, posibilidad de fallas en los componentes y complejidad de interacción entre los módulos hacen que el problema de consistencia sea complejo. – Debe haber mecanismos de control de concurrencia, procedimientos de manejo y recuperación de fallas, etc.

7 Objetivos Robustez – Es el problema mas importante – Los fallos en los canales de comunicación son mas comunes – El sistema debe ser capaz de reinicializar a un punto donde la integridad del sistema es conocida – Fiabilidad, protección y control de acceso son puntos muy importantes.

8 Transparencia Transparencia de acceso – Habilidad de acceder objetos locales y remotos en una forma uniforme. Transparencia de ubicación – El usuario no sabe donde esta ubicado el objeto, estos se referencian con nombres lógicos Transparencia de migración – El objeto se puede mover físicamente a otro nodo, pero mantiene el mismo nombre

9 Transparencia Transparencia Concurrencia – Compartir objetos sin interferirse (time-sharing) Transparencia de replicación – Consistencia entre diferentes instancias de archivos y datos. Transparencia de paralelismo – Posibilidad de correr actividades en paralelo sin necesidad de que el usuario sepa donde y cuando el las actividades se realizan

10 Transparencia Transparencia de fallas – La fallas se transforman en una degradación de rendimiento del sistema en lugar de interrupciones. Transparencia de rendimiento – Consistencia y predictibilidad del rendimiento aun con cambios de la estructura o en la distribucion de la carga.

11 Transparencia Transparencia de tamaño – Modularidad y escalabilidad sin que la percepción del sistema cambie para el usuario. Transparencia de versión – Distintas revisiones del sistema no son visibles para el usuario

12 Categorización de transparencias Objetivos del Sistema Transparencias EficienciaConcurrencia Paralelismo Rendimiento FlexibilidadAcceso Ubicación Migración Tamaño Versión ConsistenciaAcceso Replicación Rendimiento RobustezFallas Replicación Tamaño Versión

13 Mapeo de problemas con transparencias ProblemasTransparencias Comunicación Sincronización Algoritmos distribuidos Interacción y control de transparencia Planeamiento de procesos Manejo de deadlock Manejo de carga Transparencia de rendimiento Planeamiento de recursos Archivos compartidos Control de concurrencia Transparencia de recursos Manejo de fallas Configuración Redundancia Transparencia de fallas

14 Servicios Un sistema operativo es un proveedor de servicios. Los servicios mas fundamentales (primitivas del sistema) se implementan en el kernel de cada nodo Otros servicios pueden estar implementados en cualquier lugar del sistema y proveer funciones básicas (servidores de sistema) Existen también los que proveen servicios de alto nivel o de propósito especial (servicios de valor agregado)

15 Servicios primitivos Hay tres funciones fundamentales: – Comunicación – Sincronización – Multiplexación de procesadores

16 Servicios por servidores de sistema Name server or Directory server: Este es el servicio mas esencial en un sistema distribuido. Network server: Transforma las direcciones de los objetos en caminos de comunicación. Broadcast o Multicast server: Se encarga de esta funcionalidad si la red no lo soporta. Time server: Es usado para sincronizar y planear procesos. (Físico o lógico)

17 Servicios para manejar recursos File server: Repositorio de archivos. Puede ser particionado o duplicado siempre manteniendo la consistencia Print server: Servicio de impresión Servidor de procesos: Puede mover procesos de un nodo a otro basado en los recursos

18 Servicios de valor agregado Servidor de grupos: Maneja la creación y terminación de actividades de grupo. Servidor de conferencias distribuidas Servidor web

19 Modelos de arquitectura La implementación de un SD depende de la arquitectura del sistema y de la red de comunicación La arquitectura del sistema es una descripción abstracta de los componentes y sus relaciones La arquitectura de la red especifica las opciones de comunicación.

20 Arquitecturas de sistemas distribuidos Workstation-Server: La estación de trabajo provee capacidad de procesamiento local e interface con la red. Processor-Pool: Se comparte poder computacional aparte de los recursos. Modelo hibrido

21 Modelo Processor-Pool

22 Arquitectura de la red de comunicación Pueden ser conexiones punto a punto o multipunto. Multipunto – Basada en buses: Ethernet, token ring, FDDI – Switcheadas: Frame relay, ISDN, ATM La capacidad y la distancia juegan un papel importante.

23 Clases de aplicaciones cliente/servidor Proceso basado en una máquina central: – No es realmente un proceso cliente/servidor. – Entorno tradicional de grandes sistemas. Cliente Servidor (a) Proceso basado en una máquina central Lógica de presentación Lógica de aplicación Lógica de base de datos SGBD

24 Clases de aplicaciones cliente/servidor Proceso basado en el servidor: – Todo el tratamiento se hace en el servidor. – Los puestos de trabajo de los usuarios ofrecen una interfaz de usuario gráfica. Lógica de presentación Lógica de aplicación Lógica de base de datos SGBD (b) Proceso basado en el servidor

25 Clases de aplicaciones cliente/servidor Proceso basado en el cliente: – Casi todo el proceso de la aplicación se hace en el cliente. – Las rutinas de validación de datos y otras funciones lógicas de la base de datos se realizan en el servidor. Lógica de presentación Lógica de base de datos SGBD Lógica de aplicación Lógica de base de datos (d) Proceso basado en el cliente

26 Clases de aplicaciones cliente/servidor Proceso cooperativo: – El proceso de la aplicación se lleva a cabo de forma optimizada. – Compleja de instalar y mantener. Lógica de presentación Lógica de base de datos SGBD Lógica de aplicación (c) Proceso cooperativo

27 Clases de aplicaciones cliente/servidor Para los casos (c) y (d) anteriores gran parte de la carga está en el cliente. Este modelo es llamado: cliente grueso. Ha sido popularizado por herramientas como PowerBuilder, SQL Windows, etc. Con el cliente grueso se saca provecho a la capacidad computacional de la máquina del cliente. Esto también implica descargar el procesamiento de los servidores.

28 Cliente Grueso Sostener clientes gruesos implica una actualización frecuente de máquinas por la necesidad de capacidad de cómputo. También debe actualizarse las capacidades de red por los grandes volúmenes de datos en las transacciones. Es bastante engorroso mantener actualizadas las aplicaciones en los clientes. Todo lo anterior hace que a pesar de parecer atractiva, la solución del cliente grueso no sea buena.

29 Cliente Delgado El ejemplo (b) anterior representa el cliente delgado. Este enfoque imita al de host centralizado. Se lo usa como vía de migración para pasar las aplicaciones de un sistema centralizado a un entorno distribuido. La mejor representación de esta clase de cliente es con las aplicaciones adaptadas a entorno web (web enabled).

30 Arquitectura cliente/servidor de tres capas El software de aplicación está distribuido entre tres tipos de máquinas: – Máquina de usuario: Cliente delgado. – Servidor de capa intermedia: Pasarelas. Convierte protocolos. Mezcla e integra resultados de distintas fuentes de datos. – Servidor final (backend).

31 Cliente Servidor de capa intermedia (servidor de aplicaciones) Servidores finales (servidores de datos) Figura Arquitectura cliente/servidor de tres capas. Arquitectura cliente/servidor de tres capas

32 Problemas de Diseño Un sistema distribuido consiste en una serie de procesos concurrentes que acceden a recursos distribuidos a través de mensajes en un ambiente de red que no es confiable y contiene componentes que pueden no ser confiables.

33 Problemas de Diseño Modelo de Objetos – Objetos en el sistema son los procesos, archivos de datos, memoria, dispositivos, etc. – Es deseable que se representen con objetos con una interfase bien definida – Los procesos que manejan los objetos se transforman en servidores de objetos.

34 Problemas de Diseño Esquema de nombres – Para contactar un servidor se lo debe identificar – Hay tres formas de identificar un servidor Por nombrePor la dirección física o lógica Por el servicio que el servidor provee Se asumen únicos Puede haber múltiples direcciones para el mismo servidor Un servidor puede proveer varios servicios Son mas intuitivos y transparentes Contienen información estructural de la localización No contienen información de la localización

35 Problemas de Diseño Esquema de nombres – La conversión de nombres a direcciones lógicas es responsabilidad del servidor de nombres – El mapeo de direcciones lógicas a físicas es responsabilidad del servicio de red – El modelo de objetos del sistema y el esquema de nombres son muy importantes y se deben decidir en una etapa temprana del diseño del sistema

36 Problemas de Diseño Coordinación distribuida – Hay tres tipos de requerimientos de sincronización Sincronización de barrera: Un grupo de procesos debe llegar a un punto común de sincronización antes de seguir Coordinación por condición: Se debe esperar una condición para mantener algún orden de ejecución. Exclusión mutua: Hay exclusión cuando se acceden recursos compartidos

37 Problemas de Diseño Coordinación distribuida – La sincronizacion implica el conocimiento del estado de otros procesos. – La decision de coordinacion depende de protocolos distribuidos basados en mensajes. – Se puede usar un coordinador centralizado pero trae otro tipo de problemas

38 Problemas de Diseño Coordinación distribuida – Existen problemas de deadlock. – Algunas veces conviene detectar el deadlock en lugar de prevenirlo – Las soluciones para la sincronización y el deadlock intentan asimilar información de estado parcial.

39 Problemas de Diseño Comunicación entre procesos – Todo el sistema depende de esto – Modelo cliente/servidor – Remote Procedure Call (RPC) – El Multicast es muy importante. Logical Multicast probablemente sin la interacción de hardware. – El multicast debe ser confiable

40 Problemas de Diseño Recursos Distribuidos – Puede ser una distribución de cargas estáticas cuyo objetivo es el de minimizar el tiempo de ejecución de un grupo de procesos relacionados – O dinámicas, donde el objetivo es maximizar la utilización de los procesadores. – Transparencia aplicada a los datos: Memoria compartida distribuida – Coherencia y consistencia de los datos

41 Problemas de Diseño Tolerancia a fallas y seguridad – El sistema debe ser resistente a fallas y estas deben ser transparentes al usuario. – La redundancia es una propiedad inherente de los SD – Se debe mantener información de estado que permite volver a un punto de funcionamiento correcto


Descargar ppt "Sistemas Distribuidos I Conceptos de Sistemas Distribuidos y Arquitectura."

Presentaciones similares


Anuncios Google