Modelos de Sistemas Distribuidos

Modelos de Sistemas Distribuidos Facultad de Cs. de la Computación Juan Carlos Conde Ramírez Distributed Computing

Contenido 1 Introducción 2 Arquitecturas de Software 3 Modelos 4 Arquitectura de Sistemas 1 / 40

Sistema Distribuido VS Red de Computadoras Es un hecho que existe una gran confusión entre una red de computadoras y un sistema distribuido. Ésto debido a que tienen muchas cosas en común. 3 / 40

Sistema Distribuido Por ejemplo, tanto los sistemas distribuidos como las redes de computadoras necesitan mover archivos. La diferencia está en quién invoca el movimiento, el sistema o el usuario. De esta manera muchos de los conceptos analizados en redes de computadoras se relacionan con los sistemas distribuidos. 4 / 40

Sistema Distribuido Es un conjunto de computadoras independientes que aparece ante sus usuarios como un sistema consistente y único. Por lo general, tiene un modelo o paradigma único que se presenta a los usuarios. Con frecuencia, una capa de software que se ejecuta sobre el sistema operativo, denominada middleware, es la responsable de implementar este modelo. Ejemplo: La World Wide Web, en la cual todo se ve como un sólo documento (una página Web). 5 / 40

Red de Computadora En una Red de Computadoras no existe esta consistencia, modelo ni software. Los usuarios están expuestos a las máquinas reales, y el sistema no hace ningún intento porque las máquinas se vean y actúen de manera similar. Si las máquinas tienen hardware diferente y distintos sistemas operativos, eso es completamente transparente para los usuarios. Si un usuario desea ejecutar un programa de una máquina remota, debe registrarse en ella y ejecutarlo desde ahí. 6 / 40

Diferencia De hecho, un sistema distribuido es un sistema de software construido sobre una red. El software le da un alto grado de consistencia y transparencia. De este modo, la diferencia entre una red y un sistema distribuido está en el software (sobre todo en el sistema operativo), más que en el hardware. 7 / 40

Propósito I Sólo porque es posible construir un sistema distribuido no signica que necesariamente sea una buena idea. Después de todo, con la tecnología actual también es posible colocar cuatro controladores de blue-ray dentro de una computadora personal. Solamente que hacer eso no tendría sentido. 9 / 40

Propósito II Para que la construcción de un sistema distribuido valga la pena, un sistema distribuido debe: 1. Hacer que los recursos sean fácilmente accesibles. 2. Ocultar razonablemente que los recursos están distribuidos por toda la red. 3. Ser abierto. 4. Ser escalable. 10 / 40

Justicación Por lo general, los sistemas distribuidos son complejas piezas de software cuyos componentes se encuentran, por denición, dispersos en diversas máquinas. Para dominar esta complejidad, resulta crucial que los sistemas se encuentren organizados adecuadamente. Las arquitecturas de software nos dicen cómo se organizarán los componentes de software, y cómo deben interactuar. De este modo, la organización real de un sistema distribuido requiere que generemos las instancias y coloquemos los componentes del software en máquinas reales. 11 / 40

Visión general La creación de instancias nales de una arquitectura de software también se conoce como arquitectura de sistema. Existen diferentes alternativas para hacer esto: Arquitecturas centralizadas (tradicionales). En las que un solo servidor implementa la mayoría de los componentes de software. Los clientes remotos acceden a este servidor utilizando medios de comunicación simples. Arquitecturas descentralizadas. En las que las máquinas desempeñan roles casi iguales. Organizaciones híbridas. 12 / 40

Middleware I Con el objeto de ofrece la vista de un sistema único los sistemas distribuidos dan soporte a computadoras y redes heterogéneas. Se organizan a menudo en términos de una capa de software, es decir, van colocados de manera lógica entre una capa de alto nivel (usuarios y aplicaciones) y una capa subyacente (sistemas operativos y recursos básicos de comunicación). De acuerdo con lo anterior, a dicho sistema distribuido se le conoce como middleware. 13 / 40

Middleware II Un sistema distribuido organizado como middleware se extiende sobre diversas máquinas, y ofrece a cada aplicación la misma interfaz. Podemos ver 4 computadoras conectadas en red y 3 aplicaciones, de las cuales la aplicación B está distribuida entre las computadoras 2 y 3. A cada aplicación se le ofrece la misma interfaz. 14 / 40

Middleware III Este sistema distribuido proporciona: Los medios para que los componentes de una sola aplicación distribuida se puedan comunicar ente sí. Los medios para permitir la comunicación entre las diferentes aplicaciones. Al mismo tiempo, oculta, lo mejor y más razonablemente posible, las diferencias que se presentan entre el hardware y los sistemas operativos para cada aplicación 15 / 40

Técnicas de adaptación Dado que un objetivo importante de los sistemas distribuidos es separar las aplicaciones de las plataformas subyacentes mediante una capa middleware. Adoptar tal capa es una decisión arquitectónica importante para proporcionar transparecencia de distribución. Ésto nos lleva a implementar diversas técnicas para adaptar el middleware. La adaptabilidad también puede lograrse haciendo que el sistema monitoree su propio comportamiento y tome las medidas adecuadas cuando sea necesario. Esto ha dado pie a una clase de lo que ahora conocemos como sistemas autónomos. 17 / 40

Conceptos previos Se formula en términos de componentes, la forma en que los componentes interactúan entre sí, el intercambio de datos entre los componentes y en cómo es que estos elementos se conguran juntos en un sistema. Por medio de componentes y conectores podemos lograr varias conguraciones, las cuales se han clasicado en estilos arquitectónicos. Componente. Unidad modular que interactua con las interfaces requeridas. Lo imporante es que pueda ser reemplazado, a condición de respetar sus interfaces. Conector. Mecanismo que media la comunicación, coordinación o cooperación entre componentes 18 / 40

Modelos o Estilos Por ejemplo, un conector puede formarse por los medios disponibles para hacer llamadas a procedimientos (remotos), paso de mensajes, o ujo de datos. Varios estilos o modelos ya están identicados y los más importantes para sistemas distribuidos son: 1. Arquitecturas en capas. 2. Arquitecturas basadas en objetos. 3. Arquitecturas centradas en datos. 4. Arquitecturas basadas en eventos. 19 / 40

Arquitectura en capas La idea básica para el estilo en capas es sencilla: los componentes se estructuran (organizan) a modo de capas, donde al componente de la capa L i se le permite llamar a componentes de la capa subyacente L i 1, pero no del resto de capas, Una observación clave es que el control generalmente uye de capa a capa: las peticiones se mueven hacia abajo en la jerarquía mientras que los resultados se mueven hacia arriba. 20 / 40

Arquitectura basada en objetos Una organización bastante libre es la que están basadas en objetos, donde cada objeto corresponde a lo que hemos denido como componente, y estos componentes se conectan a través de un mecanismo de llamadas a procedimientos (remotos). Sin ser sorprendente, esta arquitectura de software coincide con la arquitectura de sistemas cliente-servidor que describimos antes 21 / 40

Arquitectura centrada en datos Las arquitecturas centradas en datos evolucionaron alrededor de la idea de que los procesos se comunican a través de un repositorio común (activo o pasivo). Estas arquitecturas son tan importantes como las basadas en capas y objetos. Por ejemplo: las aplicaciones en red se basan en un sistema de archivos distribuidos compartidos donde casi todas las comunicaciones se realizan a través de archivos. De manera similar, los sistemas distribuidos basados en la Web se centran bastante en datos: los procesos se comunican a través de servicios de datos compartidos basados en la Web. 22 / 40

Arquitectura basada en eventos I En las arquitecturas basadas en eventos, los procesos se comunican básicamente a través de la propagación de eventos, los que opcionalmente transportan datos. Para sistemas distribuidos, la propagación de eventos se ha asociado con lo que se conoce como sistemas de publicación-suscripción. La idea básica es que los procesos publican eventos después de los cuales el middleware asegura que sólo aquellos procesos suscritos a tales eventos los recibirán. 23 / 40

Arquitectura basada en eventos II La principal ventaja es que los procesos están libremente acoplados. En principio, no necesitan referirse uno a otro explícitamente. A esto se le conoce también como sistema desacoplado en el espacio, o referencialmente desacoplado. Las arquitecturas basadas en eventos pueden combinarse con arquitecturas centradas en datos, y arrojan lo que conocemos como espacios de datos compartidos. La esencia de los espacios de datos compartidos es que los procesos ahora también están desacoplados en el tiempo (no es necesario que ambos estén activos cuando la comunicación se lleva a cabo). 24 / 40

Arquitectura basada en eventos III Además, muchos espacios de datos compartidos utilizan una interfaz similar a la de SQL para el repositorio compartido en el sentido de que es posible acceder a los datos utilizando una descripción, en lugar de una referencia explícita, como en el caso de los archivos. 25 / 40

Problemática La transparencia de distribución requiere NEGOCIAR entre el rendimiento, la tolerancia a fallos, la facilidad de programación, etc. Como no existe una solución única que satisfaga todos los requerimientos para todas las aplicaciones distribuidas, los investigadores han abandonado la idea de que un solo sistema distribuido pueda utilizarse para cubrir el 90% de todos los casos posibles. Decidir sobre los componentes de software, sobre su interacción y ubicación, da pie a una instancia de arquitectura de software, también conocida como arquitectura de sistema. 27 / 40

Arquitecturas centralizadas En el modelo básico cliente-servidor, los procesos de un sistema distribuido se dividen en dos grupos (probablemente traslapados): 1. Un servidor que es un proceso que implementa un servicio especíco, por ejemplo, un servicio de sistema de archivos o un servicio de base de datos. 2. Un cliente es un proceso que solicita un servicio a un servidor, enviándole una petición y esperando posteriormente la respuesta. Esta interacción cliente-servidor, también conocida como comportamiento solicitud-respuesta. 28 / 40

Arquitecturas centralizadas Interacción solicitud respuesta La comunicación entre un cliente y un servidor puede implementarse mediante un protocolo simple no orientado a conexión cuando la red subyacente es muy conable, como sucede en muchas redes de área local. Cuando un cliente solicita un servicio, empaca un mensaje para el servidor identicando el servicio que requiere junto con la información de entrada necesaria. Este último, siempre esperará por una petición de entrada, la procesará, y empacará los resultados en un mensaje de respuesta. 29 / 40

Arquitecturas centralizadas Tolerancia a fallos I Un protocolo no orientado a conexión tiene la ventaja evidente de ser eciente mientras los mensajes no se pierdan o corrompan, el protocolo solicitud-respuesta esquematizado funciona bien. Desafortunadamente, implementar un protocolo tolerante a fallas ocasionales de transmisión no es algo trivial. En este caso, lo único que podemos hacer cuando el cliente no recibe un mensaje de respuesta es dejar que reenvíe la petición. Sin embargo, el problema es que el cliente no puede detectar si el mensaje de solicitud original se perdió o si la transmisión de respuesta falló. Si se perdió la respuesta, entonces reenviar una petición puede resultar en que se realice la operación dos veces. 30 / 40

Arquitecturas centralizadas Tolerancia a fallos II Por ejemplo: Si la operación fue algo como transere $10 000 de mi cuenta bancaria, evidentemente hubiera sido mejor entonces que simplemente se reportara un error. Por otra parte, si la operación fue dime cuánto dinero me queda, hubiera sido perfectamente aceptable reenviar la solicitud. Cuando una operación puede repetirse muchas veces sin ocasionar daño alguno, se dice que es idempotente. Debido a que algunas peticiones son idempotentes y otras no, debería quedar claro que no existe una solución única para tratar con los mensajes perdidos. 31 / 40

Arquitecturas centralizadas Solución alternativa Como una alternativa, muchos sistemas cliente-servidor utilizan un protocolo conable orientado a conexión. Aunque esta solución no es completamente adecuada para una LAN debido al relativo bajo rendimiento (conable), funciona perfectamente bien en sistemas WAN donde las comunicaciones son inherentemente poco conables. El servidor generalmente utiliza la misma conexión que inició un cliente, a través de la solicitud de un servicio, para enviar el mensaje de respuesta después de lo cual la conexión se interrumpe. 32 / 40

Arquitecturas centralizadas Aplicación de capas I Problemá: ¾Cómo establecer una diferencia clara entre un cliente y un servidor? Por ejemplo: Un servidor para una base de datos distribuida. Éste puede actuar continuamente como un cliente, ya que reenvía solicitudes a diferentes servidores de archivos responsables de implementar las tablas de la base de datos. En tal caso, el servidor de la base de datos no hace más que procesar consultas. 33 / 40

Arquitecturas centralizadas Aplicación de capas II Siguiendo el estilo arquitectónico en capas que explicamos antes tenemos los siguientes tres niveles: 1. El nivel de interfaz de usuario. 2. El nivel de procesamiento. 3. El nivel de datos. Como ejemplo, consideremos un motor de búsqueda en internet. 34 / 40

Arquitecturas centralizadas Ejemplo Si ignoramos todos los banners animados, las imágenes, y otras ventanas de elegante apariencia, la interfaz de usuario de un motor de búsqueda es muy sencilla: un usuario escribe una cadena de palabras clave y posteriormente se le presenta una lista de títulos de páginas web. La parte central del motor de búsqueda es un programa que transforma la cadena de palabras clave del usuario en una o más consultas para la base de datos. Posteriormente, ordena de modo jerárquico los resultados en una lista, la cual transforma en una serie de páginas HTML. El soporte para esto es formado por una amplia base de datos de páginas web que han sido previamente recuperadas e indexadas. 35 / 40

Arquitecturas centralizadas Ejemplo Esta es la organización simplicada, en tres capas diferentes, de un motor de búsqueda en Internet. Para el modelo cliente-servidor, la recuperación de información generalmente se ubica al nivel de procesamiento. 36 / 40

Arquitecturas centralizadas Consideraciones I El nivel de datos contiene los programas que mantienen los datos reales sobre los que operan las aplicaciones. Una propiedad importante es que los datos frecuentemente son persistentes, es decir, incluso si no hay aplicaciones en ejecución, los datos se almacenarán en alguna parte para su siguiente uso. En su forma más simple, el nivel de datos consiste en un sistema de archivos. Mantener la consistencia signica que metadatos tales como descripciones de tablas, restricciones de acceso, y metadatos especícos de aplicaciones también se almacenan en este nivel. 37 / 40

Arquitecturas centralizadas Consideraciones II Utilizar bases de datos relacionales ayuda a separar el nivel de procesamiento del nivel de datos, cuando el procesamiento y los datos se consideran deben ser independientes. En la mayoría de los ambientes orientados a negocios, los datos se organizan independientemente de las aplicaciones de tal manera que los cambios en la organización no afecten las aplicaciones, y que tampoco las aplicaciones afecten la organización de datos. Sin embargo, muchas aplicaciones que operan sobre complejos tipos de datos que se modelan más fácilmente en términos de objetos que en términos de relaciones. Ejemplos de tales tipos de datos van desde simples polígonos y círculos hasta representaciones de diseños de aeronáutica (sistemas CAD). 38 / 40

Arquitecturas centralizadas Arquitecturas multiniveles La diferencia entre los tres niveles lógicos anteriores sugiere la posibilidad de distribuir físicamente una aplicación cliente-servidor a través de varias máquinas. La organización más simple es tener sólo dos tipos de máquina: 1. Una máquina cliente que sólo contenga los programas de implementación del nivel de interfaz de usuario. 2. Una máquina servidor que contenga el resto, es decir, los programas para implementar el nivel de procesamiento y el nivel de datos. En esta organización el servidor maneja todo, mientras que el cliente es básicamente una Terminal Tonta, posiblemente con una linda interfaz gráca. 39 / 40

El éxito no es el nal, el fracaso no es la ruina, el coraje de continuar es lo que cuenta [Winston Churchill] Juan Carlos Conde Ramírez juanc.conde@cs.buap.mx 40 / 40