Introducción a los Sistemas Distribuidos


 

  1. Introducción a los Sistemas Distribuidos
  2. Ventajas de los Sistemas Distribuidos con Respecto a los Centralizados
  3. Ventajas de los Sistemas Distribuidos con Respecto a las PC Independientes
  4. Desventajas de los Sistemas Distribuidos
  5. Conceptos de Hardware
  6. Multiprocesadores con Base en Buses
  7. Multiprocesadores con Conmutador
  8. Multicomputadoras con Base en Buses
  9. Multicomputadoras con Conmutador
  10. Conceptos de Software
  11. Sistemas Operativos de Redes
    1. NFS: Network File System
  12. Sistemas Realmente Distribuidos
  13. Sistemas de Multiprocesador con Tiempo Compartido
  14. Aspectos del Diseño
  15. Transparencia
  16. Flexibilidad
  17. Confiabilidad
  18. Desempeño
  19. Escalabilidad
  20. Fin


Introducción a los Sistemas Distribuidos

Desde el inicio de la era de la computadora moderna (1945), hasta cerca de 1985, solo se conocía la computación centralizada [25, Tanenbaum].

A partir de la mitad de la década de los ochentas aparecen dos avances tecnológicos fundamentales:

Aparecen los sistemas distribuidos, en contraste con los sistemas centralizados.

Los sistemas distribuidos necesitan un software distinto al de los sistemas centralizados.

Los S. O. para sistemas distribuidos han tenido importantes desarrollos pero todavía existe un largo camino por recorrer.

Los usuarios pueden acceder a una gran variedad de recursos computacionales:

Un importante antecedente de las redes de computadoras lo constituye Arpanet, iniciada en 1968 en los EE. UU.

Inicio:   Fin:

Ventajas de los Sistemas Distribuidos con Respecto a los Centralizados

Una razón para la tendencia hacia la descentralización es la economía.

Herb Grosch formuló la que se llamaría “Ley de Grosch” [25, Tanenbaum]:

Los sistemas distribuidos generalmente tienen en potencia una proporción precio / desempeño mucho mejor que la de un único sistema centralizado.

Algunos autores distinguen entre:

En general se consideran sistemas distribuidos, en sentido amplio, a los sistemas en que: Ciertas aplicaciones son distribuidas en forma inherente: Una ventaja potencial de un sistema distribuido es una mayor confiabilidad: Otra ventaja importante es la posibilidad del crecimiento incremental o por incrementos:


Inicio:   Fin:

Ventajas de los Sistemas Distribuidos con Respecto a las PC Independientes

Satisfacen la necesidad de muchos usuarios de compartir ciertos datos [25, Tanenbaum] :

También con los sistemas distribuidos se pueden compartir otros recursos como programas y periféricos costosos: Otra importante razón es lograr una mejor comunicación entre las personas: La mayor flexibilidad es también importante:


Inicio:   Fin:

Desventajas de los Sistemas Distribuidos

El principal problema es el software, ya que el diseño, implantación y uso del software distribuido presenta numerosos inconvenientes [25, Tanenbaum].

Los principales interrogantes son los siguientes:

La respuesta a estos interrogantes no es uniforme entre los especialistas, pues existe una gran diversidad de criterios y de interpretaciones al respecto.

Otro problema potencial tiene que ver con las redes de comunicaciones, ya que se deben considerar problemas debidos a pérdidas de mensajes, saturación en el tráfico, expansión, etc.

El hecho de que sea fácil compartir los datos es una ventaja pero se puede convertir en un gran problema, por lo que la seguridad debe organizarse adecuadamente.

En general se considera que las ventajas superan a las desventajas, si estas últimas se administran seriamente.

Inicio:   Fin:

Conceptos de Hardware

Todos los sistemas distribuidos constan de varias cpu, organizadas de diversas formas, especialmente respecto de [25, Tanenbaum]:

Existen diversos esquemas de clasificación para los sistemas de cómputos con varias cpu: SISD (Single Instruction Single Data: un flujo de instrucciones y un flujo de datos): SIMD (Single Instruction Multiple Data: un flujo de instrucciones y varios flujos de datos): MISD (Multiple Instruction Single Data: un flujo de varias instrucciones y un solo flujo de datos): MIMD (Multiple Instruction Multiple Data: un grupo de computadoras independientes, cada una con su propio contador del programa, programa y datos): Un avance sobre la clasificación de Flynn incluye la división de las computadoras MIMD en dos grupos: Cada una de las categorías indicadas se puede clasificar según la arquitectura de la red de interconexión en: Generalmente los multiprocesadores están más fuertemente acoplados que las multicomputadoras.

Inicio:   Fin:

Multiprocesadores con Base en Buses

Constan de cierto número de cpu conectadas a un bus común, junto con un módulo de memoria (ver Figura 7.1 [25, Tanenbaum]).

Multiprocesadores con base en un bus.

Un bus típico posee al menos [25, Tanenbaum]:

Todos los elementos precedentes operan en paralelo.

Para leer una palabra de memoria, una cpu:

Para grabar el procedimiento es similar.

Solo existe una memoria, la cual presenta la propiedad de la coherencia:

El problema de este esquema es que el bus tiende a sobrecargarse y el rendimiento a disminuir drásticamente; la solución es añadir una memoria caché de alta velocidad entre la cpu y el bus: Un importante problema debido al uso de cachés es el de la “incoherencia de la memoria”: Una solución consiste en lo siguiente: Si todos los cachés realizan un monitoreo constante del bus: Un diseño con cachés monitores y de escritura es coherente e invisible para el programador, por lo que es muy utilizado en multiprocesadores basados en buses.

Inicio:   Fin:

Multiprocesadores con Conmutador

El esquema de multiprocesadores con base en buses resulta apropiado para hasta aproximadamente 64 procesadores [25, Tanenbaum].

Para superar esta cifra es necesario un método distinto de conexión entre procesadores (cpu) y memoria.

Una posibilidad es dividir la memoria en módulos y conectarlos a las cpu con un “conmutador de cruceta” (cross-bar switch):


Conmutador de cruceta.

El número de conmutadores del esquema anterior puede resultar prohibitivo:


Red omega de conmutación.


n
log 2 n
n * log 2 n
n * n
50 5,64385619 282 2.500
75 6,22881869 467 5.625
100 6,64385619 664 10.000
125 6,96578428 871 15.625
150 7,22881869 1.084 22.500
175 7,45121111 1.304 30.625
200 7,64385619 1.529 40.000
1.024 10 10.240 1.048.576
Tabla 7.1: Conmutador de cruceta versus red omega.

Conmutador de cruceta versus red omega.

Un problema importante en la red omega es el retraso:

Otra posible solución son los esquemas según sistemas jerárquicos:


Inicio:   Fin:

Multicomputadoras con Base en Buses

Es un esquema sin memoria compartida [25, Tanenbaum].

Cada cpu tiene una conexión directa con su propia memoria local.

Un problema importante es la forma en que las cpu se comuniquen entre sí.

El tráfico es solo entre una cpu y otra; el volumen de tráfico será varios órdenes de magnitud menor que si se utilizara la red de interconexión para el tráfico cpu - memoria.

Topológicamente es un esquema similar al del multiprocesador basado en un bus.

Consiste generalmente en una colección de estaciones de trabajo en una LAN (red de área local) (ver Figura 7.5 [25, Tanenbaum]).

Multicomputadora que consta de estaciones de trabajo en una LAN.

Inicio:   Fin:

Multicomputadoras con Conmutador

Cada cpu tiene acceso directo y exclusivo a su propia memoria particular [25, Tanenbaum].

Existen diversas topologías, las más comunes son la retícula y el hipercubo.

Las principales características de las retículas son:


Retícula.

Las principales características del hipercubo son:


Hipercubo de dimensión 4.

Inicio:   Fin:

Conceptos de Software

La importancia del software supera frecuentemente a la del hardware [25, Tanenbaum].

La imagen que un sistema presenta queda determinada en gran medida por el software del S. O. y no por el hardware.

Los S. O. no se pueden encasillar fácilmente, como el hardware, pero se los puede clasificar en dos tipos:

El software débilmente acoplado de un sistema distribuido: Combinando los distintos tipos de hardware distribuido con software distribuido se logran distintas soluciones:


Inicio:   Fin:

Sistemas Operativos de Redes

Una posibilidad es el software débilmente acoplado en hardware débilmente acoplado [25, Tanenbaum]:

Cada usuario tiene una estación de trabajo para su uso exclusivo: Una mejor solución consiste en un sistema de archivos global compartido, accesible desde todas las estaciones de trabajo: Los “servidores de archivos”: Las estaciones de trabajo pueden importar o montar estos sistemas de archivos: El S. O. de este tipo de ambiente debe: Todas las máquinas pueden ejecutar el mismo S. O., pero esto no es necesario.

Si los clientes y los servidores ejecutan diversos S. O., como mínimo deben coincidir en el formato y significado de todos los mensajes que podrían intercambiar.

Esquemas como este se denominan “sistema operativo de red”:


Inicio:   Fin:

NFS: Network File System

Es uno de los más conocidos y aceptado como sistema operativo de red [25, Tanenbaum].

Fue un desarrollo de Sun Microsystems, soportado también por distintos fabricantes:

Los aspectos más interesantes son los relacionados con:


La Arquitectura de NFS

La idea fundamental es permitir que una colección arbitraria de clientes y servidores compartan un sistema de archivos común.

Generalmente todos los clientes y servidores están en la misma LAN, pero esto no es necesario; por ello se puede ejecutar NFS en una WAN (“red de área amplia”).

NFS permite que cada máquina sea un cliente y un servidor al mismo tiempo.

Cada servidor de NFS exporta uno o varios de sus directorios (y subdirectorios dependientes) para el acceso por parte de clientes remotos.

Los clientes tienen acceso a los directorios exportados mediante el montaje:

Un cliente sin disco puede montar un archivo remoto en su directorio raíz; esto produce un sistema de archivos soportado en su totalidad en un servidor remoto.

Las estaciones de trabajo que no poseen discos locales pueden montar directorios remotos en donde lo deseen, en la parte superior de su jerarquía de directorios local; esto produce un sistema de archivos que es en parte local y en parte remoto.

Si dos o más clientes montan el mismo directorio al mismo tiempo:

Los archivos compartidos figuran en la jerarquía de directorios de varias máquinas y se los puede leer o escribir de la manera usual.

Protocolos de NFS

Uno de los objetivos de NFS es:

NFS logra este objetivo definiendo dos “protocolos cliente - servidor”: Un “protocolo de NFS” maneja el montaje.

Un cliente puede:

Si el nombre de la ruta de acceso es válido y el directorio especificado ha sido exportado: Algunos S. O. soportan la alternativa del “automontaje”: NFS no da soporte a la duplicación de archivos o directorios.

Otro “protocolo de NFS” es para el acceso a los directorios y archivos.

Los clientes pueden:

NFS soporta “servidores sin estado”: El “sistema de archivos remotos” (RFS) del Sistema V de UNIX no funciona así, sino que: En un “servidor sin estado”, como NFS: NFS utiliza el esquema de protección de UNIX, con los bits “rwx” para el propietario, grupo y otros.

Se puede utilizar la criptografía de claves públicas para dar validez al cliente y el servidor en cada solicitud y respuesta; el cliente malicioso no puede personificar a otro cliente, ya que no conoce su clave secreta.

Las claves utilizadas para la autentificación, así como otra información, están contenidas en el NIS:


Implantación de NFS

La implantación del código del cliente y el servidor es independiente de los protocolos NFS.

Una implementación que suele tomarse como referencia es la de Sun, que consta de tres capas (ver Figura 7.8 [25, Tanenbaum]).

Estructura de capas de NFS.

La capa superior es la de llamadas al sistema:

La capa VFS mantiene una tabla con una entrada por cada archivo abierto que es análoga a la tabla de nodos-i para los archivos abiertos en UNIX.

La capa VFS tiene una entrada por cada archivo abierto:

Para montar un sistema remoto de archivos, el administrador del sistema llama al programa mount : El núcleo: El nodo-v apunta al nodo-r.

Cada nodo-v de la capa VFS contendrá en última instancia un apuntador a un nodo-i en el S. O. local.

Es posible ver desde el nodo-v si un archivo o directorio es local o remoto y, si es remoto, encontrar su asa de archivo.

Todo archivo o directorio abierto tiene un nodo-v que apunta a un nodo-r o a un nodo-i.

Por razones de eficiencia las transferencias entre cliente y servidor se hacen en bloques grandes, generalmente de 8k:

Un criterio similar se sigue con la escritura: Otra técnica utilizada para mejorar el rendimiento es el ocultamiento o caching: Los clientes mantienen dos cachés: Cuando se necesita un nodo-i o un bloque del archivo: Un problema importante del caching es que el caché no es coherente; ej.:


Resumiendo:


Inicio:   Fin:

Sistemas Realmente Distribuidos

NFS es un ejemplo de software débilmente acoplado en hardware débilmente acoplado [25, Tanenbaum]:

Las multicomputadoras son un ejemplo de software fuertemente acoplado en hardware débilmente acoplado: Un sistema distribuido es aquel que se ejecuta en una colección de máquinas sin memoria compartida, pero que aparece ante sus usuarios como una sola computadora: También se define un sistema distribuido como aquel que se ejecuta en una colección de máquinas enlazadas mediante una red pero que actúan como un uniprocesador virtual.

Algunas de las características de los sistemas distribuidos son las siguientes:

Inicio:   Fin:

Sistemas de Multiprocesador con Tiempo Compartido

Corresponde a software fuertemente acoplado en hardware fuertemente acoplado [25, Tanenbaum].

Los ejemplos más comunes de propósito general son los multiprocesadores:

La característica clave es la existencia de una sola cola para ejecución (Ver Figura 7.9 [25, Tanenbaum]):


Multiprocesador con una sola cola de ejecución.

Los programas de los procesos están en la memoria compartida, también el S. O.

El planificador (de procesos) del S. O. se ejecuta como una “región crítica”, con ello se evita que dos cpu elijan el mismo proceso para su ejecución inmediata.

Cuando un proceso se asigna a un procesador:

Ninguna cpu tiene memoria local, es decir que todos los programas se almacenan en la memoria global compartida.

Si todas las cpu están inactivas en espera de e / s y un proceso está listo para su ejecución:

Si un proceso se bloquea en espera de e / s en un multiprocesador, el S. O. puede: Generalmente se dispondrá de un sistema de archivos tradicional, con un único caché:


Inicio:   Fin:

Aspectos del Diseño

La comparación de las tres principales formas de organizar “n” cpu se puede resumir en la Tabla 7.2 [25, Tanenbaum].

Comparación de tres formas distintas de organizar n cpu.

Los aspectos claves en el diseño de S. O. distribuidos son:


Inicio:   Fin:

Transparencia

Un aspecto muy importante es la forma de lograr la imagen de un único sistema [25, Tanenbaum].

Los usuarios deben percibir que la colección de máquinas conectadas son un sistema de tiempo compartido de un solo procesador:

Desde el punto de vista de los usuarios, la transparencia se logra cuando: La transparencia desde el punto de vista de los programas significa diseñar la interfaz de llamadas al sistema de modo que no sea visible la existencia de varios procesadores.

No es transparente un sistema donde el acceso a los archivos remotos se realice mediante:

Existen distintos tipos de transparencia en un sistema distribuido:


Inicio:   Fin:

Flexibilidad

La flexibilidad es de fundamental importancia [25, Tanenbaum].

Esquema de núcleo monolítico y de micronúcleo.

Existen dos escuelas de pensamiento en cuanto a la estructura de los sistemas distribuidos (ver Figura 7.10 [25, Tanenbaum]):

El núcleo monolítico es el S. O. centralizado aumentado con: Con núcleo monolítico: El micronúcleo es más flexible y proporciona solo cuatro servicios mínimos: Contrariamente al núcleo monolítico, el micronúcleo no proporciona el sistema de archivos, el sistema de directorios, toda la administración de procesos o gran parte del manejo de las llamadas al sistema.

El objetivo es mantener el micronúcleo pequeño.

Todos los demás servicios del S. O. se implementan generalmente como servidores a nivel usuario:

Una importante ventaja de este método es su alta modularidad:


Inicio:   Fin:

Confiabilidad

Un importante objetivo de los sistemas distribuidos es que si una máquina falla, alguna otra debe encargarse del trabajo [25, Tanenbaum].

La confiabilidad global teórica del sistema podría ser el “or” booleano de la confiabilidad de los componentes; ejemplo:

La confiabilidad práctica se ve disminuida ya que muchas veces se requiere que ciertos servidores estén en servicio simultáneamente para que el todo funcione, debido a ello algunos sistemas tienen una disponibilidad más relacionada con el “and” booleano de las componentes que con el “or” booleano.

Un aspecto de la confiabilidad es la disponibilidad, que se refiere a la fracción de tiempo en que se puede utilizar el sistema.

La disponibilidad se mejora mediante:

Los datos no deben perderse o mezclarse y si los archivos se almacenan de manera redundante en varios servidores, todas las copias deben ser consistentes.

Otro aspecto de la confiabilidad general es la seguridad, lo que significa que los archivos y otros recursos deben ser protegidos contra el uso no autorizado.

Un aspecto también relacionado con la confiabilidad es la tolerancia a fallas, según la cual las fallas se deben ocultar brindando una recuperación transparente para el usuario, aunque haya cierta degradación de la performance.

Inicio:   Fin:

Desempeño

Cuando se ejecuta una aplicación en un sistema distribuido no debe parecer peor que su ejecución en un único procesador, pero esto es difícil de lograr [25, Tanenbaum].

Algunas métricas del desempeño son:

El problema se complica por el hecho de que la comunicación entre equipos es lenta comparada con: Se requiere el uso de protocolos de comunicaciones en los extremos (procesadores) que intervienen en la comunicación, con lo que se incrementa el consumo de ciclos de procesador.

Para optimizar el desempeño frecuentemente hay que:

También se debe prestar atención al tamaño de grano de todos los cálculos:


Inicio:   Fin:

Escalabilidad

La tendencia indica que el tamaño de los sistemas distribuidos es hacia cientos de miles y aun decenas de millones de usuarios conectados [25, Tanenbaum].

Existen cuellos de botella potenciales que se debe intentar evitar en los sistemas distribuidos de gran escala:

Se deben utilizar algoritmos descentralizados con las siguientes características:


Inicio:   Fin:
 
 

Para mayor información, seleccione una opción:

Número de visitas efectuadas desde el 17/12/2001: 
 

Estadísticas diarias desde el 10/07/2002:   Free counter and web stats

Número de visitantes actuales disponible desde el 14/07/2002:

 

AddFreeStats.com Free Web Stats in real-time !  

 



Autor: lrmdavid@exa.unne.edu.ar

Ó FACENA - http://exa.unne.edu.ar

Servicios WEB: webmaster@exa.unne.edu.ar