Sistemas Distribuidos

Algunas notas sobre

Sistemas distribuidos

para estudiar de cara a los exámenes de test y/o desarrollo....



INTRODUCCIÓN. DEL MODELO CENTRALIZADO AL MODELO DISTRIBUÍDO.

EL MODELO CENTRALIZADO.

El modelo centralizado es el que sido ampliamente utilizado en los Sistemas de Información de las grandes organizaciones en décadas anteriores, mediante un Host que ejecutaba el 100% de la lógica del sistema, residiendo únicamente en el terminal de usuario las funciones de presentación. A este tipo de aplicaciones, que concentran todas las lógicas funcionales del software (presentación, negocio y acceso a datos) en un mismo componente se les denomina aplicaciones monolíticas.


La principal ventaja de este modelo es que se dispone y se procesa toda la información en la misma máquina física, con lo que el software del sistema es mucho más sencillo y fácil de gestionar.

De las desventajas se puede nombrar su poca capacidad de crecimiento o escalabilidad, ya que aunque los equipos que dan soporte a los mismos son de una capacidad extrema, una vez se llega al límite de utilización del mismo, la única posibilidad de crecimiento es la adquisición y sustitución por un nuevo equipo con más potencia y capacidad, con el agravante de que estos sistemas son de los más caros del mercado.

Otro de los problemas de este modelo en su la poca capacidad de integración con otros sistemas de información. Son prácticamente islas en los que la única posibilidad de intercambio de información se hace por medio de procesos diferidos no on-line.

Otro defecto de estos sistemas son los relativos a la disponibilidad de los mismos, derivada principalmente de la tolerancia a fallos que proporcionan ya que, a pesar de que los sistemas mainframe son de los más robustos que se conocen, cuándo se produce un error en el sistema, el sistema en su totalidad falla, haciendo que la disponibilidad en estos casos no sea la deseada.

El procesamiento cooperativo es aquel en que dos o más elementos lógicos diferentes interactúan entre sí para la realización de una tarea común. Surgió para intentar dar respuesta a los problemas y debilidades del modelo centralizado, aunque este modelo tiene sus propios problemas derivados por su propia naturaleza distribuida.

EL PROCESAMIENTO COOPERATIVO. ARQUITECTURAS DISTRIBUÍDAS DE APLICACIONES.

La arquitectura de computación distribuida, también conocida como *de procesamiento cooperativo* consiste en el desarrollo de una aplicación dividida en componentes más o menos autónomos que se ejecutan en unidades de hardware interconectadas por redes de alta velocidad.

En el procesamiento cooperativo dos o más elementos lógicos diferentes interactúan entre sí en la realización de una tarea común.


Existen diferentes definiciones del concepto de "sistema distribuído":

  • *Un sistema distribuido es aquel en el cual varios procesadores autónomos y repositorios de datos que soportan procesos y/o bases de datos, interactúan con el fin de cooperar para lograr un objetivo global. Los procesos coordinan sus actividades e intercambian información por medio de la transferencia de información a través de una red de comunicación*. Sloman & Kramer, 1987. De esta definición se pueden comenzar a sacar distintas conclusiones, como por ejemplo la idea de la utilización de un conjunto de recursos distribuidos para la realización de un trabajo común. Esta idea se ve refrendada por otras definiciones.
  • *Un sistema distribuido es una colección de computadoras independientes que aparece ante los usuarios del sistema como una única computadora* Tanenbaum, 1995. La definición de Tanenbaum establece la idea de sistema distribuido como la forma de ofrecer un servicio único a los usuarios a partir del uso de un conjunto de computadoras totalmente independientes.

Los sistemas distribuídos pretenden alcanzar un estilo arquitectónico que habilite tres cualidades:

  • Integrabilidad: de datos y aplicaciones.
  • Modificabilidad: de aplicaciones, de representación de los datos, de ubicación física de los componentes (separación de funciónes en presentación, negocio y acceso a datos).
  • Escalabilidad: si la organización crece el sistema debe acompañar y permitir el crecimiento de forma transparente para las unidades que ya están en producción.

Características de los sistemas distribuídos.

SINCRONIZACIÓN.

En los sistemas centralizados existen un reloj común que sirve para sincronizar y coordinar cualquier proceso o comunicación de mensajes. En los sistemas distribuidos, al ser la suma de varios sistemas totalmente independientes, cada uno con sus relojes de sincronización independientes, a la hora de la coordinación y paso de mensajes no existe un reloj común, con lo que se tienen que buscar formas alternativas de sincronización.

La no existencia de un reloj común es más problemático dependiendo del tipo de sistema distribuido, ya que por ejemplo si se utiliza el modelo cliente/servidor, las soluciones de sincronización son relativamente sencillas, pero sin embargo en sistemas del tipo SSI Single System Image (Imagen única del sistema), en los que el conjunto de sistemas se ve como uno solo, y que los procesos de usuario pueden ejecutar indistintamente en distintas máquinas la sincronización es algo más compleja. Además de los problemas de sincronización, por la no existencia

de reloj común, se tienen que resolver los llamados problemas de orden o causalidad: una vez ya se han ejecutado distintos trabajos en distintos nodos del sistema, es bastante complejo averiguar en que orden se han ejecutado éstos.

CONCURRENCIA.


La concurrencia global es la capacidad de que la ejecución de los distintos elementos del sistema se realice de forma paralela. Ésta es otra característica típica de los sistemas distribuidos. La gran ventaja que ofrecen es que se pueden paralelizar trabajos entre los distintos elementos, aunque en los casos en los que tienen que acceder a un recurso compartido, ej. la escritura en un mismo fichero físico, y para evitar bloqueos y estados incongruentes del sistema se tienen que utilizar algoritmos de ‘exclusión mutua’ para evitar que

no accedan en el mismo momento.

TOLERANCIA A FALLOS.

Una característica que bien gestionada supone una gran ventaja en este tipo de sistemas es que los fallos son independientes al nodo del sistema en el que se producen, con lo que en el caso de que un nodo fallara los demás podrían continuar ejecutando sus acciones. Esto permite la consecución de los trabajos con mayor efectividad, ya que el sistema en su conjunto continúa trabajando.

Eso sí, cuándo se produce un fallo en uno de los nodos del sistema, el fallo se tiene que ‘gestionar’ de forma adecuada, ya que aunque el resto del sistema continúe funcionando, el nodo ‘problemático’ puede dar lugar a resultados erróneos. Así que cuándo se produce un fallo en un nodo, generalmente se tiene que aislar del resto sistema mientras se recupera del mismo.

SISTEMAS ABIERTOS Y HETEROGÉNEOS.

Otra característica bastante importante en los sistemas distribuidos es la heterogeneidad, ya que tanto las arquitecturas, tanto los Sistemas Operativos no tienen por qué ser iguales. Esta flexibilidad es importante a la hora de ahorrar en costes, ya que aunque se tenga un nodo de un determinado fabricante, éste no tiene por qué determinar la arquitectura del resto del sistema.


OBJETIVOS PRINCIPALES QUE PERSIGUEN LOS SISTEMAS DISTRIBUÍDOS.

Los objetivos principales que buscan los sistemas distribuidos son los siguientes:

  • Transparencia
  • Fiabilidad (disponibilidad y coherencia)
  • Rendimiento
  • Escalabilidad
  • Flexibilidad
  • Seguridad

Cada uno de los distintos modelos de sistemas distribuidos requieren diferentes facetas de estos objetivos.

Transparencia

La transparencia se consigue cuándo se consigue que a ojos del usuario el sistema se comporte como si fuera un sistema centralizado:

  • El acceso a un recurso remoto deberá de ser igual que si se accediera a un recurso local.
  • Se deberá de poder acceder a los distintos recursos sin conocer la localización de los mismos, es decir, para acceder a un recurso remoto no habrá que conocer de que nodo depende.
  • Los diferentes recursos (p.e. ficheros) podrán migrar de localización sin afectar a los usuarios.
  • El acceso concurrente a un mismo recurso no afectará a los usuarios.
  • La existencia de réplicas de los recursos no afectará a los usuarios.
  • La ocurrencia de fallos en alguno de los nodos no afectará a los usuarios.
  • El crecimiento del sistema no afectará a los usuarios.
  • El posible carácter heterogéneo de los nodos del sistema no afectará a los usuarios.

Fiabilidad

La fiabilidad en los sistemas distribuidos se tiene que buscar desde dos puntos de vista distintos:

  • Fiabilidad como disponibilidad: es decir, se busca un sistema de alta disponibilidad mediante la redundancia de nodos y recursos.
  • Fiabilidad como coherencia: se tiene que buscar que la información que procesa el sistema siempre sea coherente, aspecto que en sistemas en los que se utiliza la redundancia se dificulta bastante.

Rendimiento

El rendimiento que se persigue no debe de ser peor que en un sistema centralizado y debe de ser proporcional al número de procesadores empleado. Para conseguirlo se deben de tener unas buenas políticas de equilibrado de carga. En este aspecto el principal problema es que a más número de procesadores más elementos críticos corren el riesgo de convertirse en cuellos de botella, por ejemplo la red de comunicaciones.

Escalabilidad

El diseño del sistema tiene que tratar de evitar, principalmente en sistemas que vayan a contar con un gran número de elementos de proceso, los cuellos de botella (p.e.: componentes centralizados, tablas centralizadas, algoritmos centralizados).

Si se diseña de forma cuidadosa y planificada, el que el sistema crezca mediante la adición de nuevos nodos al sistema nos proporcionará un aumento del rendimiento proporcional con el número de procesadores que añadamos.

Flexibilidad

La flexibilidad se entiende como la capacidad de ampliar o extender el sistema con nuevas funcionalidades de forma sencilla. Un ejemplo claro de la flexibilidad es la que se consigue con el uso de soluciones de sistemas abiertos, ya que al estar basados en estándares y en interfaces y protocolos públicos no se depende de ningún fabricante a la hora de extender las funcionalidades del mismo.

Modelos de sistemas distribuídos.

Cliente / Servidor.


El modelo cliente servidor

La evolución de este modelo ha generado las siguientes arquitecturas:

  • Arquitectura cliente/servidor de 2 capas: el servidor divide el servicio en dos capas, la primera de presentación y lógica de negocio, y la segunda de acceso a datos. Este modelo dificulta el mantenimiento de las aplicaciones que lo siguen, al poco estructuradas debido a que se mezclaba la presentación de las aplicaciones con la lógica de negocio.
  • Arquitectura cliente/servidor de 3 o N capas: el servidor divide el servicio en 3 o más capas. Generalmente una capa de presentación, otra de lógica de negocio, y la tercera y última de acceso a datos. La mayoría de las aplicaciones Web actuales se desarrollan en base a esta arquitectura.

Modelo Punto a Punto (P2P).

En el modelo punto a punto, las entidades que participan las hacen ‘de igual a igual’ a través de un protocolo de diálogo con primitivas de

interacción. Todos los nodos desempeñan tareas semejantes, interactuando cooperativamente como iguales para realizar una actividad distribuida o cómputo sin distinción entre clientes y servidores. Los nodos pares mantienen la consistencia de los recursos y sincronizan las acciones a nivel de aplicación.


Otros Modelos

Existen otros tipos de modelos menos importantes pero no por ellos menos extendidos:

  • Código Móvil: código que se traslada de un servidor a un cliente y que se ejecuta en el cliente (p.e. applets o activeX).
  • Agente Móvil: es un programa que se traslada en la red, de un computador a otro, realizando una tarea para alguien. (p.e. recolecta información)
  • Clientes Ligeros: en el cliente sólo se ejecuta una interfaz basada en ventanas, mientras que la aplicación si se ejecuta en un servidor remoto, usualmente muy potente (multiprocesador, clusters, etc.)

BIBLIOGRAFIA.

Bibliography

1. Bob Francis, “Cliente/servidor: el modelo de los noventa”. Datamation
2. Auerbach, “Evaluación de las arquitecturas de proceso cooperativo”. Noviembre 1990.


Si te ha gustado esta entrada, suscríbete para recibir las próximas entradas por correo electrónico. Por favor, apoya este blog.

2 comentarios:

Entradas populares