TEMA-1-INTRODUCCION-A-LOS-SISTEM...

xkuwen_

Sistemas Distribuidos

3º Grado en Ingeniería Informática

Escuela Técnica Superior de Ingeniería Informática. Campus de

Albacete
Universidad de Castilla-La Mancha

Reservados todos los derechos.

No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad.
 TEMA 1: INTRODUCCIÓN A LOS SISTEMAS DISTRIBUIDOS
Nociones básicas

Todos los elementos rodeados son sistemas distribuidos. Los sistemas que no se encuentran en el mismo lugar
son sistemas distribuidos geográficamente. En donde hay un único ordenador multiprocesador se pueden tener
computaciones distribuidas entre las diversas CPUs y también es considerado un sistema distribuido.

Sistema distribuido Colección de unidades de procesamiento interconectadas (incluyendo

multiprocesadores) cuya visión para los usuarios es como si fuera un único computador.

Ventajas
• Alta capacidad de cómputo con menor coste: 64 PCs es más barato que un PC multiprocesador de
64 procesadores
• Compartición de datos o de equipos caros.
• Adaptación a aplicaciones intrínsicamente distribuidas bancos, supermercados, reserva de
billetes…
• Mayor fiabilidad, el fallo de un componente no hace fracasar todo el sistema (aunque si degrada su
rendimiento)
• Soporte del crecimiento incremental: pueden añadirse nuevas unidades de procesamiento de forma
sencilla.

Desventajas
• La programación de aplicaciones distribuidas compleja (basada en programación concurrente) sobre
todo en entornos heterogéneos. Además en sistemas geográficamente distribuidos no existe una
referencia temporal común.
• Las características de los sistemas distribuidos (movilidad del código y datos) dificultan la
programación.
• Un sistema distribuido puede ser heterogéneo, lo cual puede requerir nuevos elementos estructurales
para homogeneizar el interfaz entre sus componentes (middleware)
• Mayor probabilidad de fallos
• Mayor vulnerabilidad al ser sistemas más abiertos.

a64b0469ff35958ef4ab887a898bd50bdfbbe91a-4928058

Reservados todos los derechos. No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad.
 A la hora de programar un sistema distribuido nunca se debe asumir que:
• La red es • La latencia es 0 • Hay un único
fiable/segura • El ancho de banda administrador
/homogénea es infinito
• La topología de la • El coste de
red no cambia transporte es 0

Transparencia

Reservados todos los derechos. No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad.
Un punto importante del diseño de los sistemas distribuidos es que se pretende ocultar al usuario los detalles
de gestión de los recursos distribuidos. Existen diferentes tipos de transparencia:
• De acceso: El acceso a recursos locales y remotos debe realizarse de la misma forma.
• De ubicación: El usuario no tiene que conocer la ubicación exacta del recurso.
• De migración: El recurso podría ser llevado de una estación a otra, de forma transparente al usuario.
• De replicación: Aunque un recurso esté replicado en varias estaciones, el usuario lo ve como uno solo.
• De concurrencia: El usuario no debe preocuparse por los problemas relativos a compartición de
recursos.
• De paralelismo: El sistema podría paralelizar una aplicación para mejorar el rendimiento, de forma
transparente para el usuario.
• De fallos: Se oculta al usuario la problemática de tratamiento y recuperación de fallos.
• De persistencia: El usuario no tiene que preocuparse por la gestión del medio soporte del recurso (si
es volátil o no).
• De seguridad: Acceso seguro a los recursos de forma simple y transparente al usuario.

Arquitectura de Sistemas Distribuidos

Los modelos arquitectónicos de los sistemas distribuidos se basan en componentes, unidades modulares con
interfaces y dependencias externas bien definidas que pueden ser reemplazables (respetando el interface).
Pueden utilizarse conectores, elementos que facilitan la comunicación, coordinación o cooperación entre
componentes. Servicios de paso de mensajes, RPC o flujos de datos (streams)

Un componente se especifica en términos de un contrato

que incluye:
• Un interface, describiendo los servicios facilitados
por el componente
• Un conjunto de interfaces de otros componentes
requeridos, de los cuales depende el componente y
deben estar presentes y conectadas para poder
utilizarlo.

La arquitectura de componentes y sus relaciones se pueden

implementar con diferentes estilos de programación:

Modelos de capas
Los componentes de nivel i pueden invocar a componentes de nivel i-1

Arquitecturas basadas en
objetos
En donde los objetos son los
componentes y se invocan
mutuamente (cliente/servidor)

Un contenedor facilita un
entorno de gestión de componentes, con las funciones:

a64b0469ff35958ef4ab887a898bd50bdfbbe91a-4928058

si lees esto me debes un besito

 • Integra un conjunto de componentes
de una determinada aplicación.
• Facilita su interrelación, realizando
de forma automática servicios como
criptografía de datos, control de
concurrencia, seguridad…
• Intercepta las interfaces de los
componentes, para poder realizar
correctamente sus funciones.

Reservados todos los derechos. No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad.
Arquitecturas centradas en datos
Existen dos modelos posibles
• Acceso directo a los datos por los
componentes, sincronizándose entre ellos.
• Acceso a los datos a través de un servidor. Servidor de ficheros distribuidos, servidor web…

Arquitecturas basadas en eventos

1. El componente publica el recurso al resto de componentes. Publish(r)
2. Los componentes suscriptores envían mensajes de suscripción al gestor del recurso del componente
que lo publicó, sobre un evento que esperan que suceda. Suscribe(e)
3. Cuando el evento se produce, el gestor lo notifica a los suscriptores. Notify(e)

Middleware
Para que el diseño de aplicaciones distribuidas no resulte tan
complejo se tiende a la estandarización para garantizar la
interoperabilidad a nivel de aplicación. Esto se consigue a través
del Middleware que ofrece un acceso uniforme a los recursos de
un sistema, con independencia de la plataforma soporte ya que el
paquete de Middleware está por encima de los sistemas operativos.
El Middleware garantiza la transparencia de la distribución.

Arquitectura de una aplicación Middleware

Un sistema distribuido está expuesto a cambios dinámicos (movilidad código, datos, dispositivos, variaciones
en la calidad de servicio de la red, fallos…).
La adaptación a los cambios debe realizarse a través de software adaptativo que no detenga el sistema, que es
lo que es capaz de hacer un middleware adaptativo.
El uso de componentes reemplazables es una solución sencilla a esto.

a64b0469ff35958ef4ab887a898bd50bdfbbe91a-4928058

si lees esto me debes un besito

 Para conseguir un Middleware adaptativo se requiere de un mecanismo de carga y descarga dinámica de
componentes. Un servidor de aplicaciones puede ayudar en la automatización de esas tareas Glassfish

Message Brokers / Broker de mensajeria

Forma de conector de un
Middleware que permite transformar
el formato de los mensajes para
lograr interoperabilidad. Basados en
reglas sintácticas de transformación.

Pueden ubicarse en nodos distintos del emisor o receptor. Middleware orientado a mensajes (MOM)
En su forma más avanzada pueden realizar operaciones complejas como la implementación del modelo
Publish/Suscribe basado en eventos: Al
publicar un evento (send),
automáticamente se envían mensajes a
todos los suscriptores al evento.

MOM implementando el modelo Publish/Suscribe

a64b0469ff35958ef4ab887a898bd50bdfbbe91a-4928058

Reservados todos los derechos. No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad.