Arquitectura de Sistemas Distribuidos

ARQUITECTURA DE SISTEMAS

DISTRIBUIDOSSistemas de información

14 DE MAYO DE 2015UNIVERSIDAD VERACRUZANA

Facultad de Contaduría y Administración

Alumnos - Matricula:

De la Cruz Martínez Fredy Timoteo zS13013435Domínguez Vela José Antonio zS13028635

19

Sistemas de Información

Tabla de contenidoIntroducció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


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


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.

19


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.

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

19


rendimiento del sistema dependa de la velocidad de ejecución de un

procesador, depende del ancho de banda y de la velocidad de los

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


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


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


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


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


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 cliente-

servidor 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 cliente-

servidor 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


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


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


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 datos-

deben 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


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 cliente-

servidor analizadas aquí son probablemente las más adecuadas.

Usos de distintas arquitecturas cliente servidor

19


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


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


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 objetos.

19


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


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.

Arquitectura de Sistemas Distribuidos

Documents

Transcript of Arquitectura de Sistemas Distribuidos