Sistemas Distribuidos Sistemas Distribuidos Por: Mariela Curiel Basado en los textos : Sistemas Distribuidos Conceptos y
Views 116 Downloads 3 File size 471KB
Sistemas Distribuidos Sistemas Distribuidos Por: Mariela Curiel Basado en los textos : Sistemas Distribuidos Conceptos y Diseño G. Coulouris, J. Dollimore, TimKinberg
Definiciones Ejemplos Desafíos en el diseño de sistemas distribuidos Modelos Arquitectónicos Modelos fundamentales para describir sistemas distribuidos
Definiciones ``Se define un sistema distribuido como aquel en el que los componentes de hardware y software, localizados en computadores unidos mediante una red, comunican y coordinan sus acciones sólo mediante el paso de mensajes´´, (c,d,k, 2001)
Definición Esta definición tiene las siguientes consecuencias: ? Concurrencia ? Inexistencia ? Fallos
de un reloj global
Independientes
1
Definiciones ``Un sistema distribuido se compone de un grupo de computadores autónomos, enlazados mediante una red y equipados con un software de sistemas distribuidos. Este software permite que los computadores coordinen sus actividades y compartan recursos.
Definiciones ``Un sistema distribuido es un grupo de computadores independientes que son percibidas por los usuarios como un único computador´´, (tanenbaum, 1995)
Definiciones Los usuarios de un sistema distribuido bien diseñado deberían percibir un sistema de computación único e integrado, aun cuando las máquinas estén dispersas geográficamente´´ (c,d,k, 1998)
Ejemplos Internet Intranets Computación Móvil
2
Desafíos Heterogeneidad
Tolerancia a Fallas
Extensibilidad Seguridad
Concurrencia Transparencia
Escalabilidad
Desafíos: Heterogeneidad La heterogeneidad se aplica en los siguientes elementos: ? Redes ? Hardware
de computadores
? Sistemas
operativos de programación
? Lenguajes
? Implementaciones
de diferentes
desarrolladores
Desafíos: Heterogeneidad Middleware: es el estrato de software que provee una abstracción de programación, así como un enmascaramiento de la heterogeneidad subyacente de las redes, hardware, sistemas operativos y lenguajes de programación. Ejem: Corba, Java RMI
Desafíos: Heterogeneidad Heterogeneidad y código móvil ? Código
Móvil: código que puede enviarse desde un computador a otro y ejecutarse en este último.
? El
concepto de máquina virtual ofrece un modo de crear código ejecutable sobre cualquier hardware
3
Desafíos: Extensibilidad
Desafíos: Extensibilidad
Es la característica que determina si el sistema puede extenderse de varias maneras. Un sistema puede ser abierto o cerrado con respecto a extensiones de hardware o de software. Para lograr la extensibilidad es imprescindible que las interfaces clave sean publicadas.
Los Sistemas Distribuidos Abiertos pueden extenderse a nivel de hardware mediante la inclusión de computadoras a la red y a nivel de software por la introducción de nuevos servicios y la reimplementación de los antiguos.
Desafíos: Seguridad
Desafíos: Seguridad
La seguridad tiene tres componentes: Confidencialidad: protección contra individuos no autorizados Integridad: protección contra la alteración o corrupción Disponibilidad: protección contra la interferencia que impide el acceso a los recursos
Otro beneficio de los sistemas abiertos es su independencia de proveedores concretos.
Existen dos desafíos que no han sido resueltos en su totalidad: ? Ataques
de denegación de servicio del código móvil
? Seguridad
4
Desafíos: Escalabilidad
Desafíos: Escalabilidad
Se dice que un sistema es escalable si conserva su efectividad cuando ocurre un incremento significativo en el número de recursos y en el número de usuarios. El diseño de SD escalables presenta los siguientes retos: Control de costo de los recursos físicos : para que un sistema con n usuarios sea escalable, la cantidad de recursos físicos necesarios para soportarlo debería ser O(n).
Controlar la degradación del rendimiento: Ejm: Los algoritmos que emplean estructuras jerárquicas se comportan mejor frente al crecimiento de la escala, que los algoritmos que emplean estructuras lineales. Evitar cuellos de botella: los algoritmos deberían ser descentralizados.
Desafíos: Escalabilidad
Desafíos: Tratamiento de Fallos
Prevenir el desbordamiento de los recursos de software
Detección de fallos: Ejem. Se pueden utilizar sumas de comprobación (checksums) para detectar datos corruptos en un mensaje. Enmarascamiento de fallos: Ejem. ? Los
mensajes pueden retransmitirse los datos
? Replicar
5
Desafíos: Tratamiento de Fallos Tolerancia de fallos: los programas clientes de los servicios pueden diseñarse para tolerar ciertos fallos. Esto implica que los usuarios tendrán también que tolerarlos. Recuperación de fallos: implica el diseño de software en el que, tras una caída del servidor, el estado de los datos puede reponerse o retractarse (rollback) a una situación anterior. Redundancia: emplear componentes redundantes.
Desafíos:Transparencia
Desafíos: Concurrencia Existe la posibilidad de acceso concurrente a un mismo recurso.La concurrencia en los servidores se puede lograr a través de threads. Cada objeto que represente un recurso compartido debe responzabilizarse de garantizar que opera correctamente en un entorno concurrente. Para que un objeto sea seguro en un entorno concurrente, sus operaciones deben sincronizarse de forma que sus datos permanezcan consistentes.
Desafíos:Transparencia
Transparencia de acceso: permite acceder a los recursos locales y remotos empleando operaciones idénticas. Transparencia de ubicación: permite acceder a los recursos sin conocer su localización.
Transparencia de replicación: permite replicar los recursos sin que los usuarios y los programadores necesiten su conocimiento. Transparencia frente a fallos: permite ocultar fallos.
Transparencia de concurrencia: permite que varios procesos operen concurrentemente sobre recursos compartidos sin interferencia mutua.
Transparencia de movilidad: permite la reubicación de recursos y clientes en un sistema sin afectar la operación de los usuarios y los programas.
6
Desafíos:Transparencia Transparencia de rendimiento: permite reconfigurar el sistema para mejorar el desempeño según varíe su carga. Transparencia al escalado: permite al sistema y a las aplicaciones expandirse en tamaño sin cambiar la estructura del sistema o los algoritmos de aplicación.
Capas de Software El término arquitectura de software se refería inicialmente a la estructuración del software como capas en un único computador. Más recientemente las capas son uno o varios procesos, localizados en el mismo o diferentes computadores, que ofrecen y solicitan servicios.
Modelos arquitectónicos Modelo Arquitectónico de un SD: trata sobre la colocación de sus partes y las relaciones entre ellas. Ejem: modelo cliente-servidor y el modelo de procesos de ¨igual a igual¨ (peerto-peer) Diferentes modelos arquitectónicos: Capas de Software Arquitecturas de Sistema ? Interfaces y Objetos ? ?
Capas de Software Plataforma: estas capas más bajas proporcionan servicio a las superiores y su implementación es dependiente de cada computador.
Aplicación de servicios
Middleware
Sistema Operativo
Plataforma Computador y Hw. de red
7
Capas de Software Aplicación de servicios
Middleware
Sistema Operativo Computador y Hw. de red
Middleware:es una capa de software cuyo propósito es enmascarar la heterogeneidad y proporcionar un modelo de programación conveniente para los programadores de aplicaciones
Capas de Software: Middleware El middleware se ocupa de proporcionar bloques útiles para la construcción de componentes de software que puedan trabajar con otros en un sistema distribuido. En particular mejora el nivel de las actividades de comunicación de los P. de aplicación soportando abstracciones como: llamadas a procedimientos remotos, comunicación entre un grupo de procesos, etc.
Capas de Software: Middleware
Capas de Software: Middleware
Ejem: Sun RPC (llamadas a procedimientos remotos), CORBA (middleware orientado a objeto), Java RMI (invocación de objetos remotos en Java), DCOM (Modelo común de objetos distribuidos de Microsoft)
El middleware también puede proporcionar otros servicios, aparte de la comunicación, para su uso en programas de aplicación. Por ejemplo: gestión de nombres, seguridad, almacenamiento persistente, etc.
8
Arquitecturas de Sistema Modelo Cliente-Servidor Servicios proporcionados por múltiples servidores Servidores proxy y caches Procesos peer-to-peer
Modelo Cliente-Servidor Invocación
Cliente
Resultado
Servidor Resultado
Servidor
Invocación
Cliente
Proceso Computador
- El servidor puede o no estar en la misma máquina del cliente - Tanto servidores como clientes pueden ser iterativos o concurrentes
Servicios proporcionados por múltiples servidores
Servidores Proxy y Caches Servidor Servidor Web Proxy
Cliente Servidor Proxy
Servidor Cliente Servidor Cliente Servidor
servicio
-Los servidores pueden dividir el conjunto de objetos en los que está basado el servicio y distribuírselos entre ellos mismos. - Pueden mantener réplicas de los objetos en cada máquina.
Cliente
Servidor Servidor Web Proxy
-Un cache es un almacén de objetos de datos utilizados recientemente. -Los caches pueden estar ubicados en los clientes o en un servidor Proxy que se puede compartir desde varios clientes. -El propósito de los servidores proxy es incrementar la disponibilidad y las prestacionesdel servicio, reduciendo la carga en las redes de área Amplia y en los servidores WEB.
9
Procesos Peer-to-Peer Servidor Proxy Aplicación
Servidor Proxy Aplicación
Código de Coord.
Código de Coord.
Servidor Proxy Aplicación Código de Coord.
Todos los procesos desempeñan tareas semejantes, interactuando cooperativamente como iguales para realizar una actividad distribuida o cómputo sin distinción entre clientes y servidores Los procesos pares mantienen la consistencia de los recursos y sincroniza las acciones a nivel de aplicación.
Otros Modelos Arquitectónicos Código Móvil Agente Móvil: es un programa que se traslada en la red, de un computador a otro, realizando una tarea para alguien. Ejem. Recolecta información. Computadores en red: se descarga desde un servidor remoto el sop y cualquier software de aplicación necesario.
Interfaces y Objetos Una interfaz de un proceso es la especificación del conjunto de funciones que se pueden invocar sobre él. En lenguajes orientados a objetos, los procesos distribuidos pueden ser construidos de una forma más orientada al objeto. Las referencias a estos objetos se pasan a otros procesos para que se pueda acceder a sus métodos de forma remota. Esta es la aproximación adoptada por CORBA y Java RMI.
Otros Modelos Arquitectónicos Clientes Ligeros: en el cliente sólo se ejecuta una interfaz basada en ventanas, mientras que la aplicación si se ejecuta en un servidor remoto, usualmente muy potente (multiprocesador, clusters, etc.)
10
Requisitos para el diseño de Arquitecturas Distribuidas
Requisitos para el diseño de Arquitecturas Distribuidas
Capacidad de respuesta: para obtener buenos tiempos de respuesta los sistemas deben estar compuestos por pocas capas de software y la cantidad de datos transferida debe ser pequeña (ejem. Uso de proxys y caches) ? Productividad: trabajos/unidad de tiempo ? Balance de cargas: applets, varios servidores o computadores para alojar un único servicio.
Calidad de Servicio Algunas aplicaciones mantienen datos críticos en el tiempo, flujos de datos que precisan ser procesados o transferidos de un proceso a otro a una tasa prefijada. QoS es la capacidad de los sistemas para satisfacer dichos límites.
Requisitos para el diseño de Arquitecturas Distribuidas
Requisitos para el diseño de Arquitecturas Distribuidas
Rendimiento ?
Calidad de Servicio El satisfacer tales exigencias depende de la disponibilidad de los recursos en los instantes adecuados. Cada recurso crítico debe reservarse para las aplicaciones que requieren QoS. Los administradores de los recursos deben proporcionar la garantía. Las solicitudes de reserva que no se puedan cumplir se rechazan.
Aspectos de Fiabilidad (que el sistema funcione correctamente) Correctitud Tolerancia de fallos Seguridad: ? Confidencialidad ? Integridad ? Disponibilidad
11
Requisitos para el diseño de Arquitecturas Distribuidas Tolerancia a Fallos: las aplicaciones estables deben continuar funcionando correctamente en presencia de fallos de hw, sw y redes. ? ?
Requisitos para el diseño de Arquitecturas Distribuidas Seguridad: necesidad de ubicar datos y otros recursos sensibles sólo en aquellos computadores equipados de un modo eficaz contra el ataque.
Se logra con redundancia Para hacer fiable un protocolo de comunicación se emplean otras técnicas. Ejem. Retransmitir el mensaje.
Modelos Fundamentales Los modelos fundamentales están implicados en una descripción más formal de las propiedades que son comunes en los modelos arquitectónicos. Ayudan a localizar los problemas clave para los diseñadores de SD. Su propósito es especificar los problemas, dificultades y amenazas que deben superarse para desarrollar sistemas distribuidos fiables.
Modelos Fundamentales Modelo de Interacción: Trata sobre el rendimiento y sobre la dificultad de poner límites temporales en un sistema distribuido Modelo de Fallos : intenta dar una especificación precisa de los fallos que se pueden producir en procesos y en canales de comunicación. Modelo de seguridad : posibles amenazas para los procesos y canales de comunicación-
12
Modelo de Interacción Trata sobre el rendimiento y sobre la dificultad de poner límites temporales en un sistema distribuido. El cómputo ocurre en procesos. Los procesos interactúan a través del paso de mensajes. En la comunicación hay retrasos. El modelo estudia como afectan estos retrasos la coordinación de los procesos.
Modelo de Interacción Rendimiento de los canales de comunicaciones: Latencia:retardo entre el envío de un mensaje por un proceso y su recepción por otro. ? Ancho de banda: cantidad total de información que se puede transmitir en un momento dado. ? Jitter o fluctuación: variación en el tiempo invertido en completar el reparto de una serie de mensajes. ?
Dos variantes del Modelo de Interacción
Dos variantes del Modelo de Interacción
Sistemas distribuidos síncronos
Sistemas distribuidos síncronos
? El
tiempo de ejecución de cada etapa de un proceso tiene límites superior e inferior conocidos. ? Cada mensaje se recibe en un tiempo limitado conocido. ? Cada proceso tiene un reloj local cuya tasa de deriva sobre el tiempo real tiene un límite conocido.
Es posible sugerir valores para esos límites pero es difícil obtener valores realistas y dar garantías sobre los valores elegidos. ? Se pueden tener timeouts. Cuando expiran significa que ha fallado el proceso. ? Hay que garantizar ciclos suficientes de procesador, capacidad de red y proveer relojes con tasa de deriva limitadas. ?
13
Dos variantes del Modelo de Interacción Sistemas distribuidos asíncronos . Son aquellos donde no existen limitaciones sobre: La velocidad de procesamiento Los retardos de transmisión de mensajes ? Las tasas de deriva del reloj. ? ?
Los sistemas reales son frecuentemente asíncronos. Pero existen problemas que no pueden resolverse con este modelo.
Ordenamiento de Eventos
Ordenamiento de Eventos Aún cuando no hay relojes precisos la ejecución de un sistema se puede describir en términos de los eventos y su ordenación. Ejemplo: 1. X envía un mensaje de reunión 2. Y y Z responden x envía y lee y responde z lee x, y y envía otra respuesta.
Ordenamiento de Eventos
envía
x
Tiempo lógico de Lamport
m1 envía
m2
y
Tiempo Físico envía
z A t1
t2
t3
m3
m1 m2
- Si los relojes pudieran sincronizarse pudiera utilizarse el tiempo Asociado localmente a c/mensaje enviado. Los mensajes en A se Mostrarían según el ordenamiento temporal.
? Los
mensajes se reciben después de su envío x envía m1 antes que y reciba m1 Y envía m2 antes que x reciba m2 ? Las respuestas se envían después que se reciben los mensajes Y recibe m1 antes de enviar m2
14
Ordenamiento de Eventos x
1
m1 envía
y
3
m2
Tiempo Físico
2 envía
z A
t1 1
Modelo de Fallos
4
envía
t2
t3m3
m1 m2
Intenta dar una explicación precisa de los fallos que se pueden producir en los procesos y en los canales de comunicación para darnos una comprensión de sus efectos. Fallos por omisión ? De
2
m1 3
? De
4
procesos comunicaciones
m2 5
1
Modelo de Fallos Fallos de procesos Ruptura accidentada del procesamiento. Es deseable si el resto de los procesos que interactúan con el proceso interrumpido, o bien funcionan correctamente o se detienen. El método de detección de ruptura descansa en timeouts.
Modelo de Fallos Fallos de procesos Fail- Stop: es cuando el resto de los procesos puede detectar con certeza que cierto proceso interrumpio su ejecución. Se puede detectar en un sistema síncrono por los timeouts.
15
Modelo de Fallos
Modelo de Fallos
Fallos por omisión de comunicaciones. ? Fallos
Fallos arbitrarios: cualquier tipo de error.
por omisión de envíos de mensajes entre los buffers
? Procesos:
? Pérdida ? Fallos
por omisión de recepción. Proceso q
Proceso p Envía m Fallos por omisión de envío Buffer de Mensajes entrantes
Canal de comunicación
Fallos por omisión del canal
Clase de Fallo
Afecta a
Recibe
Fallos por omisión de recepción
se omiten pasos del procesamiento o se realizan pasos adicionales, no intencionados. ? Canales: se corrompe el contenido de un mensaje o se repiten mensajes. Estos fallos se pueden reconocer y ocultar o enmascarar.
Buffer de Mensajes salientes
Descripción
Fail-stop (fallo-parada)
Proceso
El proceso para y deja de funcionar. Otros procesos pueden detectarlo.
Ruptura
Proceso
El proceso para y deja de funcionar. Otros procesos pueden no ser capaces de detectar su estado.
Omisión
Canal
Un mensaje en el buffer saliente nunca llega al buffer de mensajes entrantes
Omisión de Envío
Proceso
El procesos envía pero el mensaje no se coloca en el buffer de mensajes salientes
Omisión de recepción
Proceso
El mensaje llega a la cola de mensajes entrantes pero el proceso no lo recibe.
Arbitrario (bizantino)
Proceso o Canal
Transmitir mensajes arbitrariamente, comenter omisiones, un proceso puede realizar un paso incorrecto o detenerse.
Modelo de Fallos Fallos de temporización ? Existen
en los SD síncronos donde se establecen límites. Fallos de reloj y fallos de prestaciones. ? En un SDA un proceso pude terminar mas tarde pero no hay un fallo porque no se ha dado ningún tipo de garantía. ? Los SOP a tiempo real se diseñan con vistas a proporcionar garantías de temporización.
16
Modelo de Fallos Clase de Fallo
Afecta a
Descripción
Reloj
Proceso
El reloj local del proceso excede el límite de su tasa de deriva sobre el tiempo real.
Prestaciones
Proceso
El proceso excede el límite de ejecución
Prestaciones
Canal
La transmisión del mensaje toma más tiempo del límite permitido.
Modelo de Fallos Amenazas de Integridad Protocolos que retransmiten pero no usan números de secuencia para evitar que el mismo mensaje llegue duplicado. ? Usuarios mal intencionados que insertan mensajes inválidos, repiten mensajes antiguos o modifican mensajes autenticos. ?
Modelo de Fallos Enmascaramiento de fallos ? ?
Ocultar el fallo Convertirlo en un tipo razonable
Fiabilidad y comunicación uno a uno. El término comunicación fiable se define en términos de validez e integridad. Validez: cualquier mensaje en el buffer de salida llega eventualmente al buffer de mensajes entrantes. ? Integridad: el mensaje recibido es idéndico al enviado y no se reparten mensajes por duplicado ?
Modelo de Seguridad La seguridad de un SD puede lograrse asegurando los procesos y los canales empleados para sus interacciones y protegiendo los objetos que se encapsulan contra el acceso no autorizado.
17
Modelo de Seguridad
Modelo de Seguridad Protección de Objetos
Protección de Objetos ? Los
objetos pueden contener datos privados y públicos o compartidos. ? Se otorgan derechos de acceso que especifican a quien se permite realizar ciertas operaciones sobre un objeto. Los usuarios son los principales beneficiarios de estos derechos de acceso.
A cada invocación y a cada resultado se le asocia la autoridad con que se ordena. Tal autoridad se denomina principal. ? El servidor es responsable de verificar la identidad del principal tras la invocación y comprobar que dispone de los diferentes derechos para realizar operaciones sobre el objeto. ? El cliente puede comprobar la identidad del principal tras el servidor para asegurar que el resultado proviene del servidor requerido. ?
Modelo de Seguridad
Modelo de Seguridad Asegurar procesos y sus interacciones
Derechos de acceso
Objeto
Invocación Servidor
Cliente Resultado
Principal (servidor)
Principal (usuario)
red
Cierto tipo de aplicaciones son más propensas a los ataques. ? Para este tipo de aplicaciones probablemente habrá ataques a los procesos de los que se componen tales aplicaciones y a los mensajes que viajan entre los procesos. ? Cómo podemos analizar estas amenazas para derrotarlas? ?
18
Modelo de Seguridad Modelo de amenazas de seguridad El enemigo: es capaz de enviar cualquier mensaje a cualquier proceso y también de leer o copiar cualquier mensaje entre un par de procesos. El ataque puede venir de un computador legitimamente conectado o de una máquina no autorizada. Copia de m
Proceso P
m
El enemigo
m´
Modelo de Seguridad Amenazas a procesos : cualquier proceso puede recibir mensajes de otro proceso y bien pudiera no ser capaz de identificar la identidad del emisor. Los protocolos incluyen la dirección IP del emisor, pero no es un problema generar un mensaje con una dirección falsa. No conocer cuál es el origen del mensaje es una amenaza al correcto funcionamiento de clientes y servidores.
Proceso Q
Modelo de Seguridad Amenazas a canales: un enemigo puede copiar, alterar o insertar mensajes según viajen a través de la red. Otra forma es recopilar mensajes para volver a enviarlo más tarde, haciendo posible volver a enviar el mensaje más de una vez.
Modelo de Seguridad Cómo se pueden vencer las amenazas de seguridad? Criptografía y secretos compartidos Autenticación Canales seguros
19
Modelo de Seguridad Criptografía es la ciencia de mantener los mensajes seguros y la encriptación es el proceso de transformar el mensaje de forma que quede oculto el contenido. Se emplean claves secretas que conoce el emisor y receptor.
Modelo de Seguridad Canales Seguros: para construirlos se emplean técnicas de encriptamiento y autenticación. Un canal seguro es un canal de comunicación que conecta un par de procesos, cada uno de los cuales actúa en representación de un principal.
Modelo de Seguridad Autenticación: probar la identidad probada por los emisores. La técnica básica consiste en incluir dentro del mensaje un fragmento encriptado que contenga suficiente información para garantizar la autenticidad del mensaje.
Modelo de Seguridad Un canal seguro presenta las siguiente propiedades: Cada proceso conoce bien la identidad del principal en cuya representación se ejecuta el otro proceso. Asegura privacidad e integridad (protección contra la manipulación) Cada mensaje incluye un sello de carácter temporal, de tipo fisico o lógico, para prevenir el re-envío o la reordenación de los mensajes. Ejemplo: SSL (Secure Sockets Layer)
20
Modelo de Seguridad Otras posibilidades de amenaza del enemigo son: Denegación de servicio Código móvil: puede incluir código que accede o modifica los recursos que están legitimamente disponibles para los procesos del host pero no para el creador del código.
21