Cap2Coulouris - Apuntes 1 PDF

Preview

Summary

Resumen capitulo 1 couloris sistemas distribuidos...

Description

MODELOS DE SISTEMA 2.1. Introducción 2.2. Modelos arquitectónicos 2.3. Modelos fundamentales 2.4. Resumen

Un modelo arquitectónico de un sistema distribuido trata sobre la colocación de sus partes y las relaciones entre ellas. Algunos ejemplos pueden ser el modelo cliente-servidor y el modelo de procesos «de igual a igual» (peer to peer). El modelo cliente-servidor admite varias modificaciones debido a: La partición de datos o la replicación en servidores cooperativos. El uso de caché para los datos en clientes y servidores proxy. El uso de código y agentes móviles. Los requisitos para añadir o eliminar dispositivos móviles de forma conveniente. Los modelos fundamentales están implicados en una descripción más formal de las propiedades que son comunes en todos los modelos arquitectónicos. No hay un tiempo global en un sistema distribuido, por lo que los relojes en las diferentes computadores no tienen necesariamente el mismo tiempo en una que en otra. Toda comunicación entre procesos se realiza por medio de mensajes. La comunicación mediante mensajes sobre una red puede verse afectada por retrasos, puede sufrir variedad de fallos y es vulnerable a los ataques a la seguridad. Estas cuestiones se consideran en tres modelos: El modelo de interacción trata de las prestaciones y de la dificultad de poner límites temporales en un sistema distribuido, por ejemplo para la entrega de mensajes. El modelo de fallos intenta dar una especificación precisa de los fallos que se pueden producir en los procesos y en los canales de comunicación. Define comunicación fiable y procesos correctos. El modelo de seguridad discute sobre las posibles amenazas para los procesos y los canales de comunicación. Introduce el concepto de canal seguro, que lo es frente a dichas amenazas.

28

Sistemas distribuidos

2.1. INTRODUCCION. Los sistemas pensados para trabajar en entornos reales deben diseñarse para funcionar correctamente en el rango de circunstancias más amplio posible y considerando todas las dificultades y amenazas (en el cuadro que viene a continuación se describen algunos ejemplos). La discusión y los ejemplos del Capítulo 1 sugieren que sistemas distribuidos de tipos diferentes comparten importantes propiedades subyacentes y dan lugar a problemas de diseño comunes. En este capítulo se presentan las propiedades y temas de diseño comunes para los sistemas distribuidos bajo la forma de modelos descriptivos. Cada modelo está pensado para proporcionar una descripción abstracta, simplificada pero consistente, de cada aspecto relevante del diseño de un sistema distribuido. Un modelo arquitectónico define la forma en que los componentes de los sistemas interaccionan uno con otro y en cómo están vinculados con la red de computadores subyacente. En la Sección 2.2, describimos la estructura de niveles del software de sistema distribuido y los principales modelos arquitectónicos que determinan las ubicaciones y las interacciones de los componentes. Discutimos las variantes del modelo cliente-servidor, incluyendo aquellas que se deben al empleo de código móvil. Tenemos en cuenta las características de un sistema distribuido en el que se puedan añadir o quitar dispositivos móviles a conveniencia. Finalmente, contemplamos los requisitos generales de diseño para los sistemas distribuidos. En la Sección 2.3, presentamos tres modelos fundamentales que ayudan a localizar los problemas clave para los diseñadores de sistemas distribuidos. Su propósito es especificar las cuestiones, dificultades y amenazas que deben resolverse para desarrollar sistemas distribuidos que realicen correctamente, de forma fiable y segura sus tareas. Los modelos fundamentales proporcionan vistas abstractas de aquellas características de los sistemas distribuidos que afectan a sus características de confianza, corrección, fiabilidad y seguridad. Dificultades y amenazas para los sistemas distribuidos. Algunos de los problemas con los que se deben encarar los diseñadores de sistemas distribuidos son: Modos de utilización muy variables: Las partes componentes de los sistemas están sujetas a grandes variaciones en la carga de trabajo: por ejemplo, algunas páginas Web son accedidas varios millones de veces al día. Algunas partes de un sistema pueden estar desconectadas, o deficientemente conectadas, en algún momento; por ejemplo cuando están incluidos en un sistema de computadores móviles. Algunas aplicaciones, tienen requisitos especiales para comunicaciones de gran ancho de banda y baja latencia,.por ejemplo las aplicaciones multimedia. Amplio rango de entornos: Un sistema distribuido se debe acomodar a hardware, sistemas operativos y redes heterogéneas. Las redes pueden variar mucho en sus prestaciones, de hecho las redes sin cable trabajan a una fracción de la velocidad de las redes locales. Se deben soportar sistemas de escalado muy diferente, desde decenas hasta millones de computadores. Problemas internos: Relojes no sincronizados, actualizaciones conflictivas de datos, muchas formas de fallos en hardware y software implicando a componentes individuales de un sistema. Amenazas externas: Ataques a la integridad y el secreto de los datos, denegación del servicio.

2.2. MODELOS ARQUITECTONICOS La arquitectura de un sistema es su estructura en términos de componentes especificados por separado. El objetivo global es as egurar que la estructura satisfará las demandas presentes y previsibles sobre él. El diseño arquitectónico de un edificio tiene aspectos similares y determina no sólo su apariencia, sino también su estructura general y su estilo arquitectónico (gótico, neoclásico, moderno), proporcionando un marco de referencia consistente para el diseño.

Modelos de sistema

29

En esta sección, describiremos los principales modelos arquitectónicos empleados en los sistemas distribuidos: los estilos arquitectónicos de los mismos. Construimos nuestros modelos arquitectónicos en torno a los conceptos de proceso y objeto introducidos en el Capítulo 1. Un modelo arquitectónico de un sistema distribuido simplifica y abstrae, inicialmente, las funciones de los componentes individuales de dicho sistema y posteriormente considera: La ubicación de los componentes en la red de computadores, buscando definir patrones utilizables para la distribución de datos y carga de trabajo. Las interrelaciones entre los componentes, es decir, sus papeles funcionales y los patrones de comunicación entre ellos. Una simplificación inicial se obtiene clasificando los procesos entre servidores, clientes e iguales, siendo estos últimos procesos que cooperan y se comunican de forma simétrica para realizar una tarea. Esta clasificación de procesos identifica las responsabilidades de cada uno y ayuda, por tanto, a valorar sus cargas de trabajo y a determinar el impacto de los fallos en cada uno de ellos. Los resultados de este análisis pueden ser utilizados para especificar la distribución de los procesos de una forma que concuerde con los objetivos de prestaciones y fiabilidad del sistema resultante.. Se pueden construir otros sistemas dinámicos como variaciones del modelo cliente servidor: La posibilidad de mover código de un proceso a otro permite que un proceso delegue tareas en otro; por ejemplo, los clientes pueden descargar código de los servidores y ejecutarlo localmente. Los objetos y el código al que acceden puede reubicarse para reducir los retardos de acceso y minimizar el tráfico de la comunicación. Algunos sistemas distribuidos se diseñan para permitir que los computadores y otros dispositivos móviles se añadan o eliminen sin incidencias, permitiendo el descubrimiento de servicios disponibles y el ofrecer sus servicios a otros. Existen varios patrones utilizados ampliamente para la distribución del trabajo en un sistema distri buido y que tienen un impacto importante en las prestaciones y efectividad del sistema resultante. La ubicación actual de los procesos que conforman un sistema distribuido sobre una red de computadores está también influenciada por muchas características detalladas de prestaciones, fiabilidad, seguridad y coste. Los modelos arquitectónicos descritos aquí pueden proporcionar sólo una versión simplificada de los patrones de distribución más importantes. 2.2.1. CAPAS DE SOFTWARE El término arquitectura de software se refería inicialmente a la estructuración del software como capas o módulos en un único computador y más recientemente en términos de los servicios ofrecidos y solicitados entre procesos localizados en el mismo o diferentes computadores. Esta vista orientada a proceso y a servicio puede expresarse en términos de capas de servicio. Esta visión se presenta en la Figura 2.1 y se desarrolla con detalle creciente en los Capítulos 3 al 6. Un servidor es un proceso que acepta peticiones de otros procesos. Un servicio distribuido puede proveerse desde uno o más procesos servidor, es interactuando entre cada uno de ellos, y con los procesos clientes, para mantener una visión de los recursos del servicio consistente con el sistema. Por ejemplo, un servicio de tiempo de red está implementada en Internet basado en el Protocolo de Tiempo de Red (NTP, Network Time Protocol) mediante procesos servidor, corriendo sobre máquinas de Internet, que proporcionan el tiempo actual a cualquier cliente que lo solicite y ajuste su versión del tiempo actual como resultado de las interacciones con los otros. La Figura 2.1 muestra términos importantes como plataforma y middleware, que definimos a continuación: Plataforma. El nivel de hardware y las capas más bajas de software se denominan, a menudo, plataforma para sistemas distribuidos y aplicaciones. Estas capas más bajas proporcionan s ervicios

30

Sistemas distribuidos

Figu r a 2 . 1 . Ca pa s d e se r v i ci o soft w a r e y h a r d w a r e e n l os si st e m a s di st r i bu i dos.

a las que están por encima de ellas, y que son implementadas independientemente en cada computador, proporcionando una interfaz de programación del sistema a un nivel que facilita la comunicación y coordinación entre procesos. Windows para Intel x86, Sun OS para Sun SPARC, Solaris para Intel x86, Mac Os para Power PC, Linux para Intel x86 son los principales ejemplos. Middleware. Se definió en la Sección 1.4.1 como una capa de software cuyo propósito es enmascarar la heterogeneidad y proporcionar un modelo de programación conveniente para los programadores de aplicaciones. Se representa mediante procesos u objetos en un conjunto de computadores que interactúan entre sí para implementar mecanismos de comunicación y de recursos compartidos para aplicaciones distribuidas. El middleware se ocupa de proporcionar bloques útiles para la construcción de componentes software que puedan trabajar con otros en un sistema distri buido. En particular, mejora el nivel de las actividades de comunicación de los programas de apli cación soportando abstracciones como: procedimiento de invocación remota, comunicación entre un grupo de procesos, notificación de eventos, replicación de datos compartidos y transmisión de datos multimedia en tiempo real. Las comunicaciones entre grupos se considerarán en el Capítulo 4 y se tratarán con detalle en los Capítulos 11 y 14. La notificación de eventos se describirá en el Capítulo 5. La replicación de datos se discutirá en el Capítulo 14 y los sistemas multime dia en el Capítulo 15. Los paquetes de llamadas a procedimientos remotos como Sun RPC (descrito en el Capítulo 5) y sistemas de comunicación en grupo como ISIS (Capítulo 14) fueron de los primeros, y son actualmente los ejemplos de middleware más ampliamente utilizados. Entre los productos y estándares de middleware orientados al objeto están CORBA (Common Object Request Broker Architecture de OMG), invocación de objetos remotos en Java (RMI, Remote Method Invocation), Modelo Común de Objetos Distribuidos de Microsoft (DCOM) y el Modelo de Referencia para Proceso Distribuido Abierto de la ISO/ITU-T (RM-ODP, Reference Model for Open Distributed Processing). CORBA y Java RMI serán descritos en los Capítulos 5 y 17, y se pueden encontrar detalles sobre DCOM y RM -ODP en Redmond [19971 y Blair y Stefani [19971. El middleware también puede proporcionar servicios para su uso en los programas de aplicación. Existen s ervicios de infraestructuras ligadas fuertemente al modelo de programación distribuida que proporciona el middleware. Por ejemplo, CORBA ofrece una variedad de servicios que proporcionan a las aplicaciones funciones que incluyen la gestión de nombres, seguridad, transacciones, almacenamiento persistente y notificación de eventos. Alguno de los servicios de CORBA se analizará en el Capítulo 17. Los servicios de la capa superior de la Figura 2.1 son servicios específicos del dominio que utiliza el middleware , sus operaciones de comunicación y sus propios servicios.

Modelos de sistema

31

Limitaciones del middleware: Muchas aplicaciones distribuidas dependen enteramente de los servicios proporcionados por el middleware disponible, para soportar sus necesidades de comunicación y de compartir datos. Por ejemplo, una aplicación adecuada para el modelo cliente-servidor, como una base de datos de nombres y direcciones, puede basarse en middleware que proporcione sólo invocación de métodos remoto. Se ha conseguido mucho en la simplificación de la programación de los sistemas distribuidos mediante el desarrollo del soporte de middleware, aunque algunos aspectos de la confiabilidad de los sistemas precisan soporte al nivel de aplicación. Consideremos la transferencia de mensajes grandes de correo electrónico desde el servidor de correo del emisor hacia el del receptor. A primera vista es un uso sencillo del protocolo de transmisión de datos TCP (se verá en el Capítulo 3). Pero, contemplemos el problema de un usuario que intente transferir un fichero muy grande sobre una red potencialmente poco fiable. TCP proporciona algo de detección y corrección de errores, pero no puede resolver los problemas de interrupciones importantes de red. El servicio de transferencia de correo añade otro nivel de tolerancia a fa llos, manteniendo un registro de progreso y reanudando la transmisión, utilizando una nueva conexión TCP, si la primera falla. Un trabajo clásico de Saltzer, Reed y Clarke [Saltzer y otros, 1984] presenta un apunte similar y valioso sobre el diseño de sistemas distribuidos, que ellos llaman «el argumento final». Parafra seándolos: Algunas funciones relacionadas con la comunicación pueden implementarse completamente y de forma fiable sólo con el conocimiento y la ayuda de cómo es la aplicación en los puntos finales del sistema de comunicación. Por tanto, proporcionar dicha función como una característica del sistema de comunicación no siempre es sensato. (Una versión incompleta de la función proporcionada por el sistema de comunicación puede ser a veces útil como una mejora de prestaciones). Pudiera pensarse que su argumento va en contra de la idea de que todas las actividades de comunicación pueden abstraerse de la programación de aplicaciones mediante la introducción de las capas de middleware adecuadas. El núcleo de su argumento es que el funcionamiento correcto de los programas distribuidos depende de las comprobaciones, mecanismos de corrección de errores y medidas de seguridad en muy distintos niveles, algunos de los cuales requieren acceso a datos del espacio de direcciones de la aplicación. Cualquier intento de realizar comprobaciones únicamente con el sistema de comunicación garantizará sólo una parte de la corrección exigida. Es muy probable, entonces, que se esté duplicando trabajo en los programas de aplicación, malgastando esfuerzo en la programación, y lo que es más importante, añadiendo una complejidad innecesaria y realizando cómputos redundantes. No hay aquí espacio suficiente para detallar más sus argumentos, y se recomienda fuertemente la lectura del trabajo citado, que está lleno de ejemplos ilustrativos. Recientemente, uno de los autores originales señala qúe los beneficios sustanciales que trajo este argumento al diseño de Internet están en peligro por los recientes movimientos hacia la especialización de los servicios de red para satisfacer los requisitos de las aplicaciones actuales [www.reed.com]. 2.2.2. ARQUITECTURAS DE SISTEMA La división de responsabilidades entre los componentes del sistema (aplicaciones, servidores y otros procesos) y la ubicación de los componentes en los computadores en la red, es quizá el aspecto más evidente del diseño de un sistema distribuido. Sus implicaciones fundamentales es tán en las prestaciones, fiabilidad y seguridad del sistema resultante. En esta sección, se esbozan los prin cipales modelos arquitectónicos sobre los cuales se basa esta distribución de responsabilidades. En un sistema distribuido, los procesos con responsabilidades bien definidas interactúan con los otros para realizar una actividad útil. En esta sección, nuestra atención se enfocará en la colocación

32

Sistemas distribuidos

Figura 2.2. Clientes que invocan a ser vidores individuales.

de los proces os, ilustrada en la Figura 2.2, mostrando la disposición de los procesos (elipses) en los computadores (cajas grises). Utilizamos los términos invocación y resultados para etiquetar los mensajes, aunque se podrían haber etiquetado igualmente como solicitud y respuesta. Los principales tipos de modelos arquitectónicos están ilustrados en las Figuras 2.2 a la Figura 2.5 y se describen a continuación. Modelo cliente -servidor. Es la arquitectura que se cita más a menudo cuando se discute sistemas distribuidos. Históricamente es la más importante, y continúa siendo la más ampliamente utilizada. La Figura 2.2 muestra la sencilla estructura sobre la que interaccionan los procesos clientes con los procesos servidores individuales, en computadores separados, con el fin de acceder los recursos compartidos que ellos gestionan. Los servidores pueden, a su vez, ser clientes de otros servidores, como se indica en la figura Por ejemplo, un servidor Web es, a veces, un cliente de un servidor de ficheros local que gestión los ficheros en los que están almacenadas las páginas Web. Los servidores Web y la mayoría d( resto de los servicios de Internet son clientes del servicio DNS, que traduce Nombres de Dominio de Internet en direcciones de red. Otro ejemplo relacionado con Web son los buscadores, que permiten a los usuarios buscar resúmenes de la información disponible en las páginas Web de los sitie de Internet. Estos resúmenes están realizados por programas llamados escaladores (crawlers) Web que se ejecutan en segundo plano en el sitio del buscador utilizando peticiones HTTP para accedí a los servidores Web a través de Internet. Por tanto, una máquina de búsqueda es tanto un cliente como un servidor: responde a las consultas del navegador de los clientes y ejecuta Web crawler que actúan como clientes de otros servidores Web. En este ejemplo, las tareas del servidor (responder a las consultas de usuarios) y las tareas de crawler (hacer peticiones a otros servidores Web son totalmente independientes; hay muy poca necesidad de sincronizarlas y pueden ejecutarse concurrentemente. De hecho, un buscador típico debiera incluir muchos hilos (threads) de ejecución concurrente, algunos sirviendo a sus clientes y otros ejecutando crawlers Web. En el Ejercicio 2. se invita al lector a considerar el único tema de sincronización que se presenta en un buscador concurrente del tipo descrito aquí. Servicios proporcionados por múltiples servidores. Los servicios pueden implementarse como distintos procesos de servidor en computadores separados interaccionando, cuando (necesario, para proporcionar un servicio a los procesos clientes (véase la Figura 2.3). Los servid res pueden dividir el conjunto de objetos en los que está basado el servicio y distribuírselos entre ellos mismos, o pueden mantener copias replicadas de ellos en varias máquinas. Estas dos opciones se ilustran en los ejemplos siguientes. El Web proporciona un ejemplo típico de partición de datos en el que cada servidor Web administra su propio conjunto de recursos. Un usuario puede emplear un navegador para acceder al recurso en cualquiera de los servidores.