sistemas distribuidos i conceptos de sistemas distribuidos y arquitectura
TRANSCRIPT
Sistemas Distribuidos I
Conceptos de Sistemas Distribuidos y Arquitectura
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
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.
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.
Objetivos
Flexibilidad– Desde el punto de vista del sistema:
Capacidad de evolucionar y migrar. Modularidad, Escalabilidad, portabilidad y
interoperabilidad.
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.
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.
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
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
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.
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
Categorización de transparencias
Objetivos del Sistema
Transparencias
Eficiencia Concurrencia
Paralelismo
Rendimiento
Flexibilidad Acceso
Ubicación
Migración
Tamaño
Versión
Consistencia Acceso
Replicación
Rendimiento
Robustez Fallas
Replicación
Tamaño
Versión
Mapeo de problemas con transparencias
Problemas 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
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)
Servicios primitivos
Hay tres funciones fundamentales:– Comunicación– Sincronización– Multiplexación de procesadores
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)
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
Servicios de valor agregado
Servidor de grupos: Maneja la creación y terminación de actividades de grupo.
Servidor de conferencias distribuidas Servidor web
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.
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
Modelo Processor-Pool
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.
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
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
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
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 Lógica de aplicación
(c) Proceso cooperativo
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.
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.
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).
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).
Cliente
Servidor de capa intermedia(servidor de aplicaciones)
Servidores finales(servidores de datos)
Figura 13.6. Arquitectura cliente/servidor de tres capas.
Arquitectura cliente/servidor de tres capas
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.
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.
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
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
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
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
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.
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
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
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