arquitectura de sistemas distribuidos
Post on 15-Jan-2016
14 Views
Preview:
DESCRIPTION
TRANSCRIPT
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
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.
19
Sistemas de Información
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
Sistemas de Información
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
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 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
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 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
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 cliente-
servidor 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 objetos.
19
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.
top related