Sistemas Distribuidos I

Presentación del tema: "Sistemas Distribuidos I"— 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 Eficiencia: Comunication delays Effective communication primitives at the language or OS level Scheduling cambia en sistemas distribuidos Flexibilidad: User’s point of view: friendliness Ease of use interface Consistencia y robustez System point of view Evolucionar y migrar Modularidad, scalability, portabilidad, interoperabilidad Consistencia Falta de informacion global Replicacion y particion de los datos Predictability Robustez Communication links Reiniciar a un estado conocido Degradacion de performance

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 Transparencia de ubicación
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 Transparencia de replicación
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 Transparencia de rendimiento
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 Transparencia de versión
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 Eficiencia Concurrencia Paralelismo Rendimiento Flexibilidad Acceso Ubicación Migración Tamaño Versión Consistencia Replicación Robustez Fallas

13 Mapeo de problemas con transparencias
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 Lógica de presentación Lógica de aplicación Lógica de base de datos SGBD (a) Proceso basado en una máquina central

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 aplicación Lógica de base de datos Lógica de base de datos SGBD (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 aplicación Lógica de aplicación Lógica de base de datos SGBD (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 Arquitectura cliente/servidor de tres capas
Servidor de capa intermedia (servidor de aplicaciones) Servidores finales (servidores de datos) Figura 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 nombre Por 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