Arquitectura de Sistemas Distribuidos

Sistemas de Información

ARQUITECTURA DE SISTEMAS DISTRIBUIDOS Sistemas de información

Alumnos - Matricula: De la Cruz Martínez Fredy Timoteo zS13013435 Domínguez Vela José Antonio zS13028635

14 DE MAYO DE 2015 UNIVERSIDAD VERACRUZANA Facultad de Contaduría y Administración

19

Sistemas de Información

Tabla de contenido Introducción....................................................................................................... 1 Concepto........................................................................................................... 2 Ventajas y desventajas........................................................................................ 2 Ventajas............................................................................................................ 2 Desventajas....................................................................................................... 3 Tipos genéricos de Arquitecturas de sistemas distribuidos.........................................5 Arquitectura multiprocesador................................................................................ 6 Arquitecturas cliente-servidor................................................................................ 7 Modelo Cliente Ligero.......................................................................................... 9 Modelo Cliente Rico.......................................................................................... 10 Modelo Cliente-Servidor de 3 Capas....................................................................11 Arquitecturas peer-to-peer.................................................................................. 14 Arquitectura de objetos distribuidos.....................................................................16 Ventajas del modelo de objetos distribuidos..........................................................16

19

Sistemas de Información

Introducción Hoy en día todos los sistemas informáticos utilizan sistemas distribuidos, Para Tanenbaum y Van Steen (2007)

"un sistema distribuido no es más que la

colección de computadoras independientes que aparecen al usuario como un solo sistema coherente...." A partir de ello un sistema distribuido es una colección de ordenadores autónomos, enlazados por una red de ordenadores y soportados por un software que hace que la colección actúe como un servicio integrado. El presente documento tiene como finalidad describir las ventajas de los SD, porque es conveniente hacer uso de estos; así mismo analizar las desventajas que tienen. También se trataran las arquitecturas más importantes en los sistemas distribuidos.

19

Sistemas de Información

Concepto Un sistema distribuido es aquel que implica numerosas computadoras, con contraste

con los sistemas centralizados en que todos los componentes de

sistema se ejecutan en una sola computadora. La ingeniería de sistemas distribuidos tiene mucho en común con la ingeniería de cualquier otro software, pero existen cuestiones específicas que deben tenerse en cuenta cuando se diseña este tipo de sistemas.

Ventajas y desventajas Ventajas Se identifican las siguientes ventajas del uso de una aproximación distribuida para el desarrollo de sistemas:  Compartición de recursos. Un sistema distribuido permite compartir recursos hardware y software – como discos, impresoras, ficheros y compiladores – que se asocian con computadoras de una red.  Apertura. Los sistemas distribuidos son normalmente sistemas abiertos, lo que significa que se diseñan sobre protocolos estándar que permiten combinar equipamiento y software de diferentes vendedores.  Concurrencia. En un sistema distribuido, varios procesos pueden operar al mismo tiempo sobre diferentes computadoras de la red. Estos procesos pueden (aunque no necesariamente) comunicarse con otros durante su funcionamiento normal.  Escalabilidad. Al menos en principio, los sistemas distribuidos son escalables en tanto que la capacidad del sistema puede incrementarse añadiendo nuevos recursos para cubrir nuevas demandas sobre el sistema.

19

Sistemas de Información En la práctica, la red que una las computadoras individuales del sistema puede limitar la escalabilidad del sistema. Si se añaden muchas computadoras nuevas, entonces la capacidad de la red puede resultar inadecuada.  Tolerancia a defectos. La disponibilidad de varias computadoras y el potencial para reproducir información significa que los sistemas distribuidos pueden ser tolerantes a algunos fallos de funcionamiento del hardware y del software. En la mayoría de los sistemas distribuidos, se puede proporcionar un servicio degradado cuando ocurren fallos de funcionamiento; una completa pérdida de servicio sólo ocurre cuando existe un fallo de funcionamiento en la red. Para sistemas organizacionales a gran escala, estas ventajas significan que los sistemas distribuidos han reemplazado ampliamente a los sistemas heredados centralizados que fueron desarrollados en los años 80 y 90. Sin embargo, comparados con sistemas que se ejecutan sobre un único procesador o un clúster de procesadores, los sistemas distribuidos tienen varias desventajas.

Desventajas Cuando se construye un sistema distribuido, no se persigue la creación de una topología de interacciones determinada, ni el uso de ningún tipo de componente específico.

1. Complejidad. Los sistemas distribuidos son más complejos que los sistemas centralizados. Esto hace más difícil comprender sus propiedades emergentes y probar estos sistemas. Por ejemplo, en vez de que el rendimiento del sistema dependa de la velocidad de ejecución de un procesador, depende del ancho de banda y de la velocidad de los

19

Sistemas de Información procesadores de la red. Mover los recursos de una parte del sistema a otra puede afectar de forma radical al rendimiento del sistema.

2. Seguridad. Puede accederse al sistema desde varias computadoras diferentes, y el tráfico en la red puede estar sujeto a escuchas indeseadas. Esto hace más difícil el asegurar que la integridad de los datos en el sistema se mantenga y que los servicios del sistema no se degraden por ataques de denegación de servicio.

3. Manejabilidad. Las computadoras en un sistema pueden ser de diferentes tipos y pueden ejecutar versiones diferentes de sistemas operativos. Los defectos en una máquina pueden propagarse a otras máquinas con consecuencias inesperadas. Esto significa que se requiere más esfuerzo para gestionar y mantener el funcionamiento del sistema.

4. Impredecibilidad. Como todos los usuarios de la WWW saben, los sistemas distribuidos tienen una respuesta impredecible. La respuesta depende de la carga total en el sistema, de su organización y de la carga de la red. Como todos ellos pueden cambiar con mucha rapidez, el tiempo requerido para responder a una petición de usuario puede variar drásticamente de una petición a otra.

19

Sistemas de Información

Tipos de Arquitecturas de sistemas distribuidos. Cliente-servidor.- Esta arquitectura es la que estamos más acostumbrados a utilizar en entornos distribuidos. La web es un ejemplo de ello. En el modelo cliente-servidor hay dos tipos de componentes: 

Clientes: hacen peticiones de servicio. Normalmente, los clientes inician la comunicación con el servidor.



Servidores: proveen servicios. Normalmente, los servidores esperan recibir peticiones. Una vez que han recibido una petición, la resuelven y devuelven el resultado al cliente.

Arquitecturas de objetos distribuidos. En este caso, no hay distinción entre servidores y clientes, y el sistema puede ser visto como un conjunto de objetos que interaccionan cuya localización es irrelevante. No hay distinción entre un proveedor de servicios y el usuario de estos servicios. Los sistemas distribuidos se desarrollan normalmente utilizando una aproximación orientada a objetos. Estos sistemas están formados por partes independientes pobremente integradas, cada una de las cuales pueden interaccionar directamente con los usuarios o con otras partes del sistema. Algunas partes del sistema pueden tener que responder a eventos independientes. Los objetos software reflejan estas características; por lo tanto, son abstracciones naturales para los componentes de sistemas distribuidos. Los componentes en un sistema distribuido pueden implementarse en diferentes lenguajes de programación y pueden ejecutarse en tipos de procesadores completamente diferentes. Los modelos de datos, la representación de la información y los protocolos de comunicación pueden ser todos diferentes. Un sistema distribuido, por lo tanto, requiere software que pueda gestionar estas partes distintas, y asegurar que dichas partes se puedan comunicar e intercambiar

19

Sistemas de Información datos. El término middleware se usa para hacer referencia a ese software; se sitúa en medio de los diferentes componentes distribuidos del sistema.

19

Sistemas de Información

Arquitectura multiprocesador El modelo más simple de un sistema distribuido es un sistema multiprocesador en el que el software está formado por varios procesos que pueden (aunque no necesariamente) ejecutarse sobre procesadores diferentes. Este modelo es común en sistemas grandes de tiempo real. Estos sistemas recogen información, toman decisiones usando esta información y envían señales a los actuadores que modifican el entorno del sistema.

Lógicamente, los procesos relacionados con la recopilación de información, toma de decisiones y control de actuadores podrían ejecutarse todos sobre un único procesador bajo el control de un planificador (scheduler). El uso de múltiples procesadores mejora el rendimiento y adaptabilidad del sistema. La distribución de procesos ente los procesadores puede ser predeterminada (esto es común en sistemas críticos) o puede estar bajo el control de un despachado (dispcher) que decide que procesos se asignan a cada procesador.

Los

sistemas

de

software

compuestos

de

múltiples

procesos

no

son

necesariamente sistemas distribuidos. Si se dispone de más de un procesador, entonces se puede implementar la distribución, pero los diseñadores del sistema no siempre consideran forzosamente cuestiones de distribución durante el proceso de diseño. La aproximación de diseño para este tipo de sistemas es esencialmente la misma para sistema de tiempo real.

19

Sistemas de Información

Arquitecturas cliente-servidor En esta aproximación, el sistema puede ser visto como un conjunto de servicio que se proporcionan a los clientes que hacen uso de dichos servicios. Los servidores y los clientes se tratan de forma diferente en estos sistemas. En una arquitectura cliente-servidor, una aplicación se modela como un conjunto de servicios proporcionado por los servidores y un conjunto de clientes que usan estos servicios. Los clientes necesitan conocer que servidores están disponibles, pero normalmente no conocen la existencia de otros clientes. Clientes y servidores son procesos diferentes que representan un modelo lógico de una arquitectura distribuida cliente-servidor. Varios procesos servidores pueden ejecutarse sobre un único procesador servidor, por lo tanto, no hay necesariamente una correspondencia 1:1 ente procesos y procesadores en el sistema. Cuando hacemos referencia a clientes y servidores, nos referimos a los procesos lógicos en vez de a las computadoras físicas sobre las que se ejecutan. El diseño de sistemas clientes-servidor debería reflejar la estructura lógica de la aplicación que se está desarrollando. Una forma de ver una aplicación se muestra en la siguiente figura, que muestra una aplicación estructurada en tres capas.

19

Sistemas de Información La capa de presentación está relacionada con la presentación de la información al usuario y con toda la interacción con él. La capa de procesamiento de la aplicación está relacionada con la implementación de la lógica de la aplicación, y la capa de gestión de datos está relacionada con todas las operaciones sobre la base de datos. En los sistemas centralizados, estas capas no es necesario que estén claramente separadas. Sin embargo, cuando se está diseñando un sistema distribuido, deberían hacerse una clara distinción entre ellas, de forma que sea posible distribuir cada capa sobre una computadora diferente.

La arquitectura cliente-servidor más simple se denomina arquitectura clienteservidor de dos capas, en la que una aplicación se organiza como un servidor (o múltiples servidores idénticos) y un conjunto de clientes. Las arquitecturas clienteservidor de dos capas a su vez pueden ser de dos tipos: 1. Modelo de cliente ligero (thin-client). En un modelo de cliente ligero, todo el procesamiento de las aplicaciones y la gestión de los datos se llevan a cabo en el servidor. El cliente simplemente es responsable de la capa de presentación del software. 2. Modelo de cliente rico (fat-client) En este modelo, el servidor solamente es responsable de la gestión de los dato. El software del cliente implementa la lógica de la aplicación y las interacciones con el usuario del sistema.

19

Sistemas de Información Una arquitectura de dos capas con clientes ligeros es la aproximación más simple que se utiliza cuando los sistemas heredados centralizados evolucionan a una arquitectura cliente-servidor. La interfaz de usuario para estos sistemas se migra a PCs, y la aplicación en si misma actúa como un servidor y maneja todo el procesamiento de la aplicación y gestión de datos.

Modelo Cliente Ligero Un modelo de cliente ligero también puede implementarse cuando los clientes son dispositivos de red sencillos en lugar de PCs o estaciones de trabajo. El dispositivo de red ejecuta un navegador de internet y la interfaz de usuario es implementada a través de ese sistema.

Una gran desventaja del modelo de cliente ligero es que ubica una elevada carga de procesamiento tanto en el servidor como en la red. El servidor es responsable de todos los cálculos, y esto puede implicar la generación de un tráfico significativo en la red entre el cliente y el servidor. Los dispositivos de computación modernos disponen de una gran cantidad de potencia de procesamiento, la cual es bastante poco usada en la aproximación de cliente ligero.

Modelo Cliente Rico El modelo de cliente rico hace uso de esta potencia de procesamiento disponible y distribuye tanto el procesamiento de la lógica de la aplicación como la representación al cliente. El servidor es esencialmente un servidor de transacciones que gestiona todas las transacciones de la base de datos. Un ejemplo de este tipo de arquitectura es la de los sistemas bancarios ATM, en donde cada ATM es un cliente y el servidor es un mainframe que procesa la

19

Sistemas de Información cuenta del cliente en la base de datos. El hardware de los cajeros automáticos realiza una gran cantidad de procesamiento relacionado con el cliente y asociado a la transacción.

Se puede observar que los ATM no se conectan directamente con la base de datos de clientes sino con un monitor de teleproceso. Un monitor de teleproceso o gestor

de

transacciones

es

un

sistema

middleware

que

organiza

las

comunicaciones con los clientes remotos y serializa las transacciones de los clientes para su procesamiento en la base de datos. El uso de transacciones serializadas significa que el sistema puede recuperarse de los defectos sin corromper los datos del sistema.

Aunque el modelo de cliente rico distribuye el procesamiento de forma más efectiva que un modelo de cliente ligero, la gestión del sistema es más compleja. La funcionalidad de la aplicación se expande ente varias computadoras. Cuando la aplicación software tiene que ser modificada, esto implica la reinstalación en cada computador cliente. Esto puede significar un coste importante si hay cientos de clientes en el sistema.

Sistema ATM cliente-servidor

Modelo Cliente-Servidor de 3 Capas La aparición del código móvil (como los applets de java y los controles Active X), que pueden descargarse en un cliente desde un servidor, ha permitido el

19

Sistemas de Información desarrollo de sistemas clientes-servidor que son algo intermedio entre los modelos de cliente ligero y rico. Algunas de las aplicaciones de procesamiento de software pueden descargarse en el cliente como código móvil, aligerando así la carga en el servidor. La interfaz de usuario se crea usando un navegador web que incluye utilidades de construcción de programas para ejecutar el código descargado.

El problema con una aproximación cliente-servidor de dos capas es que las tres capas: lógicas - presentación, procesamiento de la aplicación y gestión de datosdeben asociarse con dos computadoras, el cliente y el servidor. Aquí puede haber problemas con la escalabilidad y rendimiento si se elige el modelo de cliente ligero, o problemas con la gestión del sistema si se usa el modelo de cliente rico. Para evitar estos problemas, una aproximación alternativa es usar la arquitectura cliente-servidor de tres capas. En esta arquitectura, la presentación, el procesamiento de la aplicación y la gestión de los datos son procesos lógicamente separados que se ejecutan sobre procesadores diferentes.

Arquitectura Cliente-Servidor en 3 capas

El uso de una arquitectura de tres capas en este caso permite optimizar la transferencia de información entre el servidor web y el servidor de base de datos. Las

comunicaciones

entre

estos

sistemas

pueden

usar

protocolos

de

comunicación de bajo nivel muy rápidos. Para manejar la recuperación de información de la base de datos se utiliza un middleware eficiente que soporte consultas a la base de datos en SQL.

19

Sistemas de Información Las arquitecturas cliente-servidor de tres capas y las variante multicapa que distribuyen el procesamiento de la aplicación entre varios servidores son intrínsecamente más escalables que las arquitecturas de dos capas. El tráfico de la red se reduce al contrario que con las arquitecturas de dos clapas de cliente ligero. El procesamiento de la aplicación es la parte más volátil del sistema, y puede ser fácilmente actualizada debido a que está localizada centralmente. El procesamiento, en algunos casos, puede distribuirse entre la lógica de la aplicación y los servidores de gestión de datos, en cuyo caso permite una respuesta más rápida a las peticiones de los clientes.

Los diseñadores de las arquitecturas cliente-servidor deben tener en cuenta una serie de factores cuando eligen la arquitectura más adecuada. En la figura siguiente se muestran las situaciones en las cuales las arquitecturas clienteservidor analizadas aquí son probablemente las más adecuadas.

Usos de distintas arquitecturas cliente servidor

19

Sistemas de Información

Arquitecturas peer-to-peer Los sistemas peer-to-peer (p2p) son sistemas descentralizados en los que los cálculos pueden llevarse a cabo en cualquier nodo de la red y, al menos en principio, no se hacen distinciones entre clientes y servidores. En las aplicaciones peer-to-peer, el sistema en su totalidad se diseña para aprovechar la ventaja de la potencia computacional y disponibilidad de almacenamiento a través de una red de computadoras potencialmente enorme. Los estándares y protocolos que posibilitan las comunicaciones a través de los nodos están embebidos en la propia aplicación, y cada nodo debe ejecutar una copia de dicha aplicación.

En principio, en los sistemas peer-to-peer cada nodo en la red podría conocer cualquier otro nodo, podría conectarse con él, y podría intercambiar datos. En la práctica, por supuesto, esto es imposible, ya que los nodos se organizan dentro de “localidades” con algunos nodos que actúan como puentes a otras localidades de nodos. La Figura anterior muestra esta arquitectura p2p descentralizada. En una arquitectura descentralizada, los nodos en la red no son simplemente elementos funcionales, sino que también son interruptores de comunicaciones que pueden encaminar los datos y señales de control de un nodo a otro.

19

Sistemas de Información Basándonos en la figura anterior, Si n1 emite una búsqueda de un documento que está almacenado en n10, esta búsqueda se encamina a través de los nodos n3, n6 y n9 hasta llegar a n10.

Esta arquitectura descentralizada tiene ventajas obvias en tanto que es altamente redundante, y por lo tanto es tolerante a defectos y tolerante a nodos desconectados de la red. Sin embargo, existen sobrecargas obvias en el sistema ya que la misma búsqueda puede ser procesada por muchos nodos diferentes y hay una sobrecarga significativa en comunicaciones entre iguales replicadas. Un modelo de arquitectura p2p alternativo que parte de una arquitectura p2p pura es una arquitectura semi-centralizada en la que, dentro de la red, uno o más nodos actúan como servidores para facilitar las comunicaciones entre los nodos.

Arquitectura P2P semi-centralizada En una arquitectura semi-centralizada, el papel del servidor es ayudar a establecer contacto entre iguales en la red o para coordinar los resultados de un cálculo. Por ejemplo, si la figura anterior representa un sistema de mensajería instantánea, entonces los nodos de la red se comunican con el servidor (indicado por líneas discontinuas), para encontrar qué otros nodos están disponibles. Una vez que éstos son encontrados, se pueden establecer comunicaciones directas y la conexión con el servidor es innecesaria. Por lo tanto, los nodos n2, n3, n5 y n6 están en comunicación directa.

19

Sistemas de Información

Arquitectura de objetos distribuidos En el modelo cliente-servidor de un sistema distribuido, los clientes y los servidores son diferentes. Los clientes reciben servicios de los servidores y no de otros clientes; los servidores pueden actuar como clientes recibiendo servicios de otros servidores, pero sin solicitar servicios de clientes; los clientes deben conocer los servicios que ofrece cada uno de los servidores y deben conocer como contactar con cada uno de estos servidores. Los componentes fundamentales del sistema son objetos que proporcionan una interfaz a un conjunto de servicios que ellos suministran. Otros objetos realizan llamadas a estos servicios sin hacer ninguna distinción lógica entre un cliente (el receptor de un servicio) y un servidor (el proveedor de un servicio). Los objetos pueden distribuirse a través de varias computadoras en una red y comunicarse a través de un middleware. A este middleware se lo denomina intermediario de peticiones de objetos. Su misión es proporcionar una interfaz transparente entre los objetos. Proporciona un conjunto de servicios que permiten la comunicación entre los objetos y que estos sean añadidos y eliminados del sistema.

Ventajas del modelo de objetos distribuidos Las ventajas del modelo de objetos distribuidos son las siguientes: 

Permitir al diseñador del sistema retrasar decisiones sobre dónde y cómo deberían proporcionarse los servicios. Los objetos que proporcionan servicios pueden ejecutarse sobre cualquier nodo de la red. Por lo tanto, la distinción entre los modelos de cliente rico y ligero es irrelevante, ya que no hay necesidad de decidir con antelación donde se sitúa la lógica de aplicación

de

los

19

objetos.

Sistemas de Información 

Es una arquitectura muy abierta que permite añadir nuevos recursos si es necesario.

Se

han

desarrollado

e

implementado

estándares

de

comunicación de objetos que permiten escribir objetos en diferentes lenguajes de programación para comunicarse y proporcionar servicios entre ellos.



El sistema es flexible y escalable. Se pueden crear diferentes instancias del sistema proporcionando los mismos servicios por objetos diferentes o por objetos reproducidos para hacer frente a las diferentes cargas del sistema. Pueden añadirse nuevos objetos a medida que la carga del sistema se incrementa



sin

afectar

al

resto

de

los

objetos

del

sistema.

Si es necesario, es posible reconfigurar el sistema de forma dinámica mediante la migración de objetos a través de la red. Esto puede ser importante donde haya fluctuación en los patrones de demanda de servicios. Un objeto que proporciona servicios puede migrar al mismo procesador que los objetos que demandan los servicios, en lo que mejora el rendimiento del sistema.

Una arquitectura de objetos distribuidos puede ser usada como un modelo lógico que permita estructurar y organizar el sistema. En este caso se debe pensar en cómo proporcionar las funcionalidades de la aplicación únicamente en términos de servicios y combinaciones de servicios.

La principal desventaja de las arquitecturas de objetos distribuidos es que son mucho más complejas de diseñar que los sistemas cliente-servidor. Los sistemas cliente-servidor parecen ser la forma más natural de concebir a los sistemas. Estos reflejan muchas transacciones humanas en las que la gente solicita y recibe servicios de otra gente especializada en proporcionar dichos servicios. Es más

19

Sistemas de Información difícil pensar en una provisión de servicios generales, y todavía no tenemos una gran experiencia en el diseño y desarrollo de objetos de negocio de grano grueso.

19