Apunte - Introducci N A Los Sistemas Distribuidos Ok

Introducción a los sistemas distribuidos
Definiciones y características
Un sistema distribuido se caracteriza por ser un conjunto de procesadores (nodos), cada
uno de ellos con su propia memoria local, que no es compartida, y con su propio reloj. Sus
componentes se comunican entre sí y coordinan sus acciones a través de diversas redes,
como los buses de alta velocidad únicamente mediante el paso de mensajes, es decir, es
una colección de nodos débilmente acoplados e interconectados por una red de
comunicaciones. Desde el punto de vista de un nodo concreto de un sistema distribuido,
el resto de los nodos y sus respectivos recursos son remotos, mientras que sus propios
recursos son locales. Es casi seguro que todos hemos utilizado algún tipo de servicio
distribuido.
Las aplicaciones de los sistemas distribuidos van desde proporcionar un acceso

transparente a los archivos dentro de una organización, a servicios de almacenamiento de
archivos y fotos en la nube a gran escala, pasando por el análisis empresarial de
tendencias en grandes conjuntos de datos, el procesamiento paralelo de datos científicos,
etc. De hecho, el ejemplo más básico de sistema distribuido es uno con el que
probablemente todos estemos muy familiarizados: Internet.
Podemos definir a un sistema distribuido de la siguiente forma:
Un sistema distribuido es aquel que administra los recursos de una colección de

computadoras independientes que aparecen ante los usuarios del sistema como una
única computadora.
Los nodos de un sistema distribuido pueden variar en tamaño y función. Pueden incluir
pequeños microprocesadores, computadoras personales y grandes sistemas informáticos
de propósito general. Estos procesadores reciben varios nombres, como procesadores,
sitios, máquinas y hosts, dependiendo del contexto en el que se mencionen.
Principalmente utilizamos sitio para indicar la ubicación de una máquina y nodo para
referirnos a un sistema específico en un sitio. Los nodos pueden existir en una
configuración cliente-servidor, una configuración peer-to-peer, o un híbrido de éstas. En la
configuración común cliente-servidor, un nodo en un sitio, el servidor, tiene un recurso
que otro nodo, el cliente (o usuario), desea utilizar. En una configuración de igual a igual,
© Universidad de Palermo. Prohibida la reproducción total o parcial de imágenes y textos. 1

no hay servidores ni clientes. En su lugar, los nodos comparten responsabilidades por igual
y pueden actuar tanto de clientes como de servidores.
Cuando varios sitios están conectados entre sí por una red de comunicación, los usuarios
de los distintos sitios pueden intercambiar información. A bajo nivel, los mensajes se
transmiten entre sistemas, de la misma forma que los mensajes se transmiten entre
procesos en el sistema de mensajes de un solo computador. Dado el paso de mensajes,
toda la funcionalidad de nivel superior que se encuentra en los sistemas autónomos
puede ampliarse para abarcar el sistema distribuido. Estas funciones incluyen el
almacenamiento de archivos, la ejecución de aplicaciones y las llamadas a procedimientos
remotos (RPC). Hay cuatro razones principales para construir sistemas distribuidos:
compartir recursos, aumentar la velocidad de cálculo, la fiabilidad y la comunicación.
Compartición de recursos
Si varios sitios diferentes, con diferentes capacidades, están conectados entre sí, entonces
un usuario en un sitio puede ser capaz de utilizar los recursos disponibles en otro. Por
ejemplo, un usuario del sitio A puede consultar una base de datos ubicada en el sitio B.
Mientras tanto, un usuario del sitio B puede acceder a un archivo que reside en el sitio A.
En general, la compartición de recursos en un sistema distribuido proporciona
mecanismos para compartir archivos en sitios remotos, procesar información en una base
de datos distribuida, imprimir archivos en sitios remotos, utilizar dispositivos de hardware
especializados remotos, como un supercomputador o una unidad de procesamiento
gráfico (GPU), y realizar otras operaciones.
Aceleración de los cálculos
Si un cálculo concreto puede dividirse en una serie de cálculos de menor envergadura que
pueden ejecutarse simultáneamente, un sistema distribuido nos permite distribuir la serie
de cálculos entre los distintos sitios. Estos cálculos de menor envergadura pueden
ejecutarse simultáneamente y, por tanto, aumentar la velocidad de cálculo. Esto es
especialmente importante cuando se procesan grandes conjuntos de datos a gran escala
(como el análisis de grandes cantidades de datos de clientes en busca de tendencias).
Además, si un sitio concreto está sobrecargado de peticiones, algunas de ellas pueden
trasladarse o redirigirse a otros sitios menos cargados. Este movimiento de trabajos se

denomina equilibrio de carga, o compartición de carga, y es habitual entre los nodos de
sistemas distribuidos y otros servicios prestados en Internet.
Fiabilidad
Si falla una instalación en un sistema distribuido, las restantes pueden seguir funcionando,
lo que confiere al sistema una mayor fiabilidad. Si el sistema está compuesto por múltiples
instalaciones autónomas de gran tamaño (es decir, computadoras de uso general), la falla
de una de ellas no debería afectar al resto. Si, por el contrario, el sistema está compuesto
por máquinas diversificadas, cada una de las cuales es responsable de alguna función
crucial del sistema (como el servidor web o el sistema de archivos), entonces un solo falla
puede detener el funcionamiento de todo el sistema. En general, con una redundancia
suficiente (tanto en hardware como en datos), el sistema puede seguir funcionando,
aunque fallen algunos de sus nodos.
La falla de un nodo o sitio debe ser detectado por el sistema, y puede ser necesaria una
acción apropiada para recuperarse de la falla. El sistema no debe seguir utilizando los
servicios de ese sitio. Además, si la función del sitio que ha fallado puede ser asumida por
otro sitio, el sistema debe garantizar que la transferencia de función se produce
correctamente. Por último, cuando el sitio averiado se recupere o se repare, deben existir
mecanismos para integrarlo de nuevo en el sistema sin problemas.
Comunicación
Cuando varios sitios están conectados a través de una red de comunicaciones, los usuarios
de distintos nodos pueden intercambiar información. A bajo nivel, los mensajes se pasan
entre sistemas de forma similar a como se pasan los mensajes entre procesos en los
sistemas de mensajería ya comentados. Con un mecanismo de paso de mensajes, toda la
funcionalidad de alto nivel que puede encontrarse en los sistemas autónomos puede
ampliarse para abarcar el sistema distribuido. Estas funciones incluyen la transferencia de
archivos, los inicios de sesión, el correo electrónico y las llamadas a procedimientos
remotos (RPC).
La ventaja de un sistema distribuido es que estas funciones pueden realizarse a grandes

distancias. Dos personas en nodos geográficamente distantes pueden, por ejemplo,
colaborar en un proyecto. Al transferir los archivos del proyecto, conectarse a los sistemas

remotos del otro para ejecutar programas e intercambiar mensajes para coordinar el
trabajo, los usuarios minimizan las limitaciones inherentes al trabajo a distancia.
Las ventajas de los sistemas distribuidos han provocado una tendencia a la baja en todo el
sector. Muchas empresas llevan tiempo sustituyendo sus computadoras centrales por
redes de computadoras personales, obteniendo mejor funcionalidad por el mismo costo,
más flexibilidad a la hora de ubicar recursos y ampliar instalaciones, mejores interfaces de
usuario y un mantenimiento mucho más sencillo.
Resumiendo, como ventajas y desventajas tendríamos el siguiente cuadro:
Ventajas
Economía
Los microprocesadores proporcionan mejor relación precio / rendimiento que cualquier

mainframe.
Velocidad
Un sistema distribuido puede tener mayor poder de cómputo que un mainframe.
Distribución inherente
Ciertas aplicaciones son distribuidas en forma inherente, porque utilizan máquina que
están separadas a cierta distancia. Por ejemplo, una cadena de supermercados tiene su
stock, pero conviene que cada supermercado maneje el suyo, pero sin embargo en cierto
momento podría interesar a cierto sector conocer el stock total de todas las sucursales.
Confiabilidad
Al estar distribuido el procesamiento en muchas máquinas, la caída de una de ellas sólo

generaría la caída de un pequeño sector del sistema.
Crecimiento por incrementos
Se puede añadir poder de cómputos en pequeños incrementos
Desventajas
Seguridad
Un acceso sencillo también se aplica a datos secretos

Software
Aún existe poco software para los sistemas distribuidos.
Redes
La red se puede saturar o causar otros problemas.
Características básicas de un sistema distribuido
Por su parte, como características básicas de un sistema distribuido podemos mencionar a

las siguientes:
Concurrencia
Cada integrante de la red realiza trabajos independientes, pero también pueden compartir
recursos en modo concurrente. Se debe proteger al sistema de los probables conflictos de
concurrencia.
Inexistencia de reloj global
Cada máquina tiene su propio reloj y estos tienen límite de precisión, por lo tanto, a través
de ellos no se puede lograr una sincronización perfecta.
Fallas independientes
Cualquier componente de la red puede fallar sin que el resto de los componentes perciban
esta falla.
Ejemplos de sistemas distribuidos
Como ejemplos de sistemas distribuidos podemos mencionar a:
Internet
Es un sistema distribuido muy grande constituido por una colección de redes de diferentes
tipos interconectadas y permite que un programa que se está ejecutando en cualquier
parte dirija mensajes a otros programas en cualquier otra parte. Los programas se pueden
ejecutar en programas conectados a la red e interactúan mediante el pasaje de mensajes
empleando un medio de comunicación común.
Intranets
Es una porción de Internet, con las mismas características, pero tiene un límite de acción
que permite hacer cumplir con políticas de seguridad. Puede estar constituida por una o

varias redes LAN en este último caso enlazadas por conexiones backbone. Una intranet
puede brindarlos mismos servicios de Internet, pero limitados a su zona de acción y
también podría integrarse a Internet a través de un router.
Términos vinculados con los sistemas operativos distribuidos
Resulta conveniente definir en este momento ciertos términos altamente vinculados con
los sistemas operativos distribuidos:
Servicio
Es el encargado de gestionar en un sistema de computadoras una colección de recursos

relacionados que presenta su funcionalidad a los usuarios y aplicaciones. Por ejemplo, un
servicio de archivos brinda las operaciones que permiten leer, borrar y escribir archivos.
Servidor
Es el programa en ejecución (proceso) en un computador en red que acepta peticiones de

los programas que se están ejecutando en otros computadores para realizar un servicio y
responder adecuadamente.
Clientes
Son los programas en ejecución (procesos) solicitantes de servicios al servidor. Cuando un

cliente realiza una petición se dice que realiza una invocación al servidor.
Breve repaso de una clasificación del hardware

La clasificación realizada por Michael Flynn (1966) es la más usada, aunque en el mejor
caso sólo se la puede tomar como una sencilla aproximación. Esta clasificación de Flynn
está basada en dos conceptos: corrientes o flujos de instrucciones y corrientes o flujos de
datos.
Un flujo de instrucciones es el conjunto de instrucciones secuenciales que son

ejecutadas por un único procesador mononúcleo, y un flujo de datos es el flujo
secuencial de datos requeridos por el flujo de instrucciones.
Un programa que calcula el promedio de una lista de temperaturas tiene un flujo de

datos. Otro que calcula la temperatura promedio de cada uno de 100 termómetros
esparcidos en todo el mundo tiene 100 flujos de datos. Los 2 flujos, instrucciones y datos,
son hasta cierto punto independientes, de modo que existen cuatro combinaciones como

se muestran en la tabla anterior. Con estas consideraciones, Flynn clasifica los sistemas en
cuatro categorías.
Un programa que calcula el promedio de una lista de temperaturas tiene un flujo de

datos. Otro que calcula la temperatura promedio de cada uno de 100 termómetros
esparcidos en todo el mundo tiene 100 flujos de datos. Los 2 flujos, instrucciones y datos,
son hasta cierto punto independientes, de modo que existen cuatro combinaciones como
se muestran en la tabla anterior. Con estas consideraciones, Flynn clasifica los sistemas en
cuatro categorías.
Una computadora con un flujo de instrucciones y uno de datos se llama SISD (Single
Instructionstream, Single Data Stream). Todas las computadoras tradicionales de un
procesador caen dentro de esta categoría desde las computadoras personales hasta los
grandes mainframes. Las computadoras SISD representan la mayoría de las máquinas
seriales. Tienen una UCP que ejecuta una
instrucción en un momento dado y busca o
guarda un dato en un momento dado. Este
es el concepto de arquitectura en serie de
von Neumann donde, en cualquier
momento, sólo se está ejecutando una
SISD
única instrucción. A menudo a los SISD se
les conoce como computadoras en serie escalares. Todas las máquinas SISD poseen un
registro simple que se llama contador de programa que asegura la ejecución en serie del
programa. Conforme se van leyendo las instrucciones de la memoria, el contador de
programa se actualiza para que apunte a la siguiente instrucción a procesar en serie.
Prácticamente ninguna computadora puramente SISD se fabrica hoy en día ya que la
mayoría de los procesadores modernos incorporan algún grado de paralelización como es
la segmentación de instrucciones o la posibilidad de lanzar dos instrucciones a un tiempo
(superescalares).

La siguiente categoría es SIMD (Single Instructionstream, Multiple Data Stream), con un
flujo de instrucciones y varios flujos de datos. Este tipo se refiere a computadoras con un
procesador y varias UAL´s para así ejecutar una misma instrucción con varios juegos de
datos en forma simultánea o
paralela. Al igual que las MISD,
las SIMD soportan
procesamiento vectorial
(matricial) asignando cada
elemento del vector a una
unidad funcional diferente para
procesamiento concurrente. Por
ejemplo, el cálculo de la paga
para cada trabajador en una
empresa consiste en repetir la
misma operación sencilla para
SIMD cada trabajador; si se dispone
de una arquitectura SIMD esto se puede calcular en paralelo para cada trabajador. Por
esta facilidad en la paralelización de vectores de datos (los trabajadores formarían un
vector) se les llama también procesadores matriciales. Las máquinas SIMD son útiles para
los cómputos que repiten los mismos cálculos en varios conjuntos de datos, por ejemplo,
sumando todos los elementos de 64 vectores independientes. También los arreglos de
procesadores están en esta categoría. Hay un conjunto de unidades de procesamiento
cada una ejecutando la misma operación sobre datos distintos. Podemos dividir al grupo
SIMD en dos subgrupos. El primero para supercomputadoras numéricas y otras máquinas
que operan con vectores, realizando la misma operación con cada elemento del vector. En
el segundo grupo están aquellas máquinas de tipo paralelo, en las que una unidad de
control maestro envía instrucciones a muchas UAL’s independientes.
La categoría MISD (Multiple Instruction Stream, Single Data Stream), corresponde a un

sistema con un flujo de varias instrucciones y un flujo de datos. En esta categorización hay
n procesadores, cada uno recibiendo una instrucción diferente y operando sobre el mismo
flujo de datos.
Tenemos dos formas de ver el flujo de datos de la figura. Una es considerar la clase de
máquinas que requerirían que unidades de procesamiento diferentes recibieran
instrucciones distintas operando sobre los mismos datos (FD2). Esta clase de arquitectura
ha sido clasificada por numerosos arquitectos de computadores como impracticable o

imposible, y en estos momentos
no existen ejemplos que
funcionen siguiendo este
modelo. Otra forma de
interpretar los MISD es como una
clase de máquinas donde un
mismo flujo de datos (FD1) fluye a
través de numerosas unidades
procesadoras. Arquitecturas
altamente segmentadas, como
los arrays sistólicos o los
procesadores vectoriales, son
MIDS
clasificadas a menudo bajo este
tipo de máquinas. Las arquitecturas segmentadas, o encauzadas, realizan el
procesamiento vectorial a través de una serie de etapas, cada una ejecutando una función
particular produciendo un resultado intermedio. La razón por la cual dichas arquitecturas
son clasificadas como MISD es que los elementos de un vector pueden ser considerados
como pertenecientes al mismo dato, y todas las etapas del cauce representan múltiples
instrucciones que son aplicadas sobre ese vector.
Por último, está el esquema MIMD (Multiple Instruction Stream, Multiple Data Stream),
que significa un grupo de CPU’s independientes, cada una con su propio contador de
programa y datos, que operan
como parte de un sistema más
grande. Todos los sistemas
distribuidos y la mayoría de los
procesadores en paralelo caen
dentro de esta categoría. Las
MIMD son las más complejas, pero
son también las que
potencialmente ofrecen una
mayor eficiencia en la ejecución
concurrente o paralela. Aquí la
concurrencia implica que no sólo
MIMD hay varios procesadores operando
simultáneamente, sino que además

hay varios procesos ejecutándose también al mismo tiempo. También podemos dividir a la
categoría MIMD en dos grupos: uno formado por aquellas que tienen una memoria
central compartida, que por lo general se llaman multiprocesadores, sistemas paralelos o
sistemas centralizados y el otro por aquellas que no la comparten. Estas últimas han
recibido diversos nombres como multicomputadoras, computadoras de memoria privada,
computadoras distribuidas o computadoras de memoria desarticulada. Asimismo, cada
una de estas dos categorías, multiprocesadores y multicomputadoras, se puede dividir
según la arquitectura de interconexión.
Cabe acotar que, la taxonomía de Flynn ha demostrado funcionar bastante bien para la
tipificación de sistemas, y se ha venido usando desde hace varias décadas por la mayoría
de los arquitectos de computadoras. Sin embargo, los avances en tecnología y diferentes
topologías, han llevado a sistemas que no son tan fáciles de clasificar dentro de los 4 tipos
de Flynn. Por ejemplo, los procesadores vectoriales no encajan adecuadamente en esta
clasificación, ni tampoco las arquitecturas híbridas. Para solucionar esto se han propuesto
otras clasificaciones, donde los tipos SIMD y MIMD de Flynn se suelen conservar, pero que
sin duda no han tenido el éxito de la de Flynn. Además, podemos decir que, al existir una
división borrosa entre MIMD y SIMD, aparecieron las categorías FPMD y SPMD, ninguna
de ellas definida por Flynn, pero ambas muy usadas en la actualidad:
 FPMD (Few Program Multiple Data), algo similar a SPMD, puesto que se copia un
número reducido de programas.
 SPMD (Single Program Multiple Data), es aquella en la que un mismo programa es
copiado y ejecutado por todos los procesadores, operando sobre diferentes datos.
Puede ser considerada como un caso particular de MIMD.
Otro ejemplo para mencionar es el de las computadoras paralelas, que aparecen tanto
como configuraciones SISD, SIMD o MIMD. De estas tres, las SIMD parecen las más
apropiadas para aplicaciones específicas, mientras que, la tendencia arquitectural para las
futuras computadoras de propósito general apunta a las MIMD con memorias distribuidas
proveyendo un espacio de direccionamiento globalmente compartido.
Clasificación del software. Tipos de sistemas distribuidos

Cada una de las estructuras de hardware que se acaban de analizar requerirá un tipo de
sistema operativo. Sin embargo, a éstos no se los puede agrupar tan fácilmente como al
hardware. Se podría hacer una división sencilla clasificando a los sistemas operativos en

débilmente acoplados y fuertemente acoplados. Los primeros permiten que las máquinas
y los usuarios de un sistema distribuido sean independientes entre sí, pero interactúen en
cierto grado cuando sea necesario. Los segundos estarían conformados por todos aquellos
sistemas que no permitirían tal independencia de máquinas y usuarios.
Por ejemplo, un grupo de computadoras donde cada una tiene su procesador, su

memoria, su propio disco y sistema operativo, pero comparten ciertos recursos: un
plotter, una impresora láser, cualquier otro periférico o una base de datos en una red LAN.
Por su parte, los fuertemente acoplados podrían ser el caso de un multiprocesador
dedicado a la ejecución de un programa de ajedrez en paralelo, donde a cada procesador
se le asigna un tablero para su evaluación y dedica su tiempo en la evaluación de este
tablero y todos los que se puedan generar a partir de él. Al finalizar la evaluación el
procesador informa el resultado y se le asigna un nuevo tablero.
Si se observa que se han desarrollado cuatro tipos de sistemas distribuidos según el

hardware y dos según el software, entonces deberían existir ocho combinaciones de
hardware y software; sin embargo, sólo existen tres, pues para el usuario es transparente
el tipo de conexión, y son: el sistema operativo en red, el sistema operativo distribuido y
el sistema operativo multiprocesador. La siguiente tabla es un resumen de las
características de cada una de estas tres clases de sistema operativo.
Sistema Operativo de Sistema Operativo Sistema Operativo de

Elemento
Red Distribuido Multiprocesador
¿Se ve como un monoprocesador
No Sí Sí
virtual?
¿Tienen todos que ejecutar el
No Sí Sí
mismo sistema operativo?
¿Cuántas copias del sistema
N N 1
operativo existen?
¿Cómo se logra la comunicación? Archivos compartidos Mensajes Memoria compartida
¿Se requiere un acuerdo entre

Sí Sí No
los protocolos de la red?
¿Existe una cola de ejecución? No No Sí
¿Existe una semántica bien

definida para los archivos Por lo general no Sí Sí
compartidos?
De estos tres, en esta sección, describiremos las dos primeras categorías: los sistemas
operativos de red y los sistemas operativos distribuidos. Los sistemas operativos de red

son más sencillos de implementar, pero, en general, más difíciles de acceder y utilizar para
los usuarios que los sistemas operativos distribuidos, que ofrecen más funciones.
Sistemas operativos de red
Un sistema operativo de red proporciona un entorno en el que los usuarios pueden

acceder a recursos remotos (implementando la compartición de recursos) iniciando sesión
en la máquina remota adecuada o transfiriendo datos de la máquina remota a sus propias
máquinas. Actualmente, todos los sistemas operativos de uso general, e incluso los
sistemas operativos integrados como Android e iOS, son sistemas operativos de red.
Inicio de sesión remoto
Una función importante de un sistema operativo de red es permitir a los usuarios

conectarse remotamente. Para ello, Internet ofrece el comando ssh. Este comando da
lugar a la formación de una conexión de socket encriptada entre la máquina local y el
computador remoto. Una vez establecida la conexión, el software de red crea un enlace
bidireccional transparente, de forma que todos los caracteres introducidos por el usuario
se envían a un proceso de la máquina remota y toda la salida de ese proceso se devuelve
al usuario. El proceso en la máquina remota pide al usuario un nombre de usuario y una
contraseña. Una vez recibida la información correcta, el proceso actúa como un proxy
para el usuario, que puede utilizar la máquina remota como cualquier usuario local.
Transferencia remota de archivos
Otra función importante de un sistema operativo de red es proporcionar un mecanismo

para la transferencia remota de archivos de una máquina a otra. En un entorno de este
tipo, cada computador mantiene su propio sistema de archivos local. Si un usuario en un
sitio (digamos, Raúl en Mendoza) quiere acceder a un archivo propiedad de Betsy ubicado
en otra computadora (digamos, en Buenos Aires), entonces el archivo debe ser copiado
explícitamente de la computadora en Buenos Aires a la computadora en Mendoza. La
comunicación es unidireccional e individual, de modo que otros usuarios en esos sitios
que deseen transferir un archivo, digamos Martin en Buenos Aires a Karen en Mendoza,
deben igualmente emitir un conjunto de comandos. Internet ofrece un mecanismo para
este tipo de transferencia con el protocolo de transferencia de archivos (FTP) y el
protocolo más privado de transferencia segura de archivos (SFTP).

Almacenamiento en la nube
Las aplicaciones básicas de almacenamiento en la nube permiten a los usuarios transferir

archivos de forma muy similar al FTP. Los usuarios pueden subir archivos a un servidor en
la nube, descargarlos al computador local y compartirlos con otros usuarios del servicio en
la nube mediante un enlace web u otro mecanismo de compartición a través de una
interfaz gráfica. Algunos ejemplos comunes son Dropbox y Google Drive. Un punto
importante sobre SSH, FTP y las aplicaciones de almacenamiento en la nube es que
requieren que el usuario cambie de paradigma. FTP, por ejemplo, requiere que el usuario
conozca un conjunto de comandos totalmente diferente de los comandos normales del
sistema operativo. Con SSH, el usuario debe conocer los comandos apropiados en el
sistema remoto. Por ejemplo, un usuario en una máquina Windows que se conecta
remotamente a una máquina UNIX debe cambiar a comandos UNIX mientras dure la
sesión SSH. (En redes, una sesión es una ronda completa de comunicación, que a menudo
comienza con un inicio de sesión para autenticar y termina con un cierre de sesión para
finalizar la comunicación). Con las aplicaciones de almacenamiento basadas en la nube, es
posible que los usuarios tengan que iniciar sesión en el servicio en la nube (normalmente
a través de un navegador web) o en la aplicación nativa y, a continuación, utilizar una serie
de comandos gráficos para cargar, descargar o compartir archivos. Obviamente, a los
usuarios les resultaría más cómodo no tener que utilizar una serie de comandos
diferentes. Los sistemas operativos distribuidos están diseñados para resolver este
problema.
Sistemas operativos distribuidos
En un sistema operativo distribuido, los usuarios acceden a los recursos remotos del
mismo modo que acceden a los recursos locales. La migración de datos y procesos de un
sitio a otro está bajo el control del sistema operativo distribuido. Dependiendo de los
objetivos del sistema, éste puede implementar la migración de datos, la migración de
cálculos, la migración de procesos o cualquier combinación de éstas.
Migración de datos
Supongamos que un usuario del sitio A desea acceder a datos (como un archivo) que
residen en el sitio B. El sistema puede transferir los datos mediante uno de dos métodos
básicos. Un método de migración de datos consiste en transferir todo el archivo al sitio A.
A partir de ese momento, todo acceso al archivo es local. Cuando el usuario ya no necesita

acceder al archivo, se envía una copia del archivo (si se ha modificado) al sitio B. Incluso si
sólo se ha realizado un cambio modesto en un archivo grande, deben transferirse todos
los datos. Este mecanismo puede considerarse un sistema FTP automatizado. Este método
se utilizó en el sistema de archivos Andrew, pero resultó ser demasiado ineficaz.
El otro enfoque consiste en transferir al sitio A sólo las partes del archivo necesarias para
la tarea inmediata. Si más adelante se necesita otra porción, se realizará otra
transferencia. Cuando el usuario ya no quiera acceder al archivo, cualquier parte de este
que haya sido modificada deberá enviarse de nuevo al sitio B. Obsérvese la similitud con la
paginación bajo demanda. La mayoría de los sistemas distribuidos modernos utilizan este
enfoque.
Sea cual sea el método utilizado, la migración de datos incluye algo más que la mera
transferencia de datos de un sitio a otro. El sistema también debe realizar varias
traducciones de datos si los dos sitios implicados no son directamente compatibles, por
ejemplo, si utilizan diferentes representaciones de códigos de caracteres o representan
números enteros con un número u orden de bits diferente.
Migración de cálculos
En algunas circunstancias, es posible que queramos transferir el cálculo, en lugar de los

datos, a través del sistema; este proceso se denomina migración de cálculo. Por ejemplo,
consideremos un trabajo que necesita acceder a varios archivos grandes que residen en
diferentes sitios, para obtener un resumen de esos archivos. Sería más eficiente acceder a
los archivos en los sitios donde residen y devolver los resultados deseados al sitio que
inició el cálculo. En general, si el tiempo necesario para transferir los datos es mayor que
el tiempo necesario para ejecutar el comando remoto, debe utilizarse el comando remoto.
Un cálculo de este tipo puede realizarse de diferentes maneras. Supongamos que el

proceso P desea acceder a un archivo en el sitio A. El acceso al archivo se realiza en el sitio
A y podría iniciarse mediante una RPC. Una RPC utiliza protocolos de red para ejecutar una
rutina en un sistema remoto. El proceso P invoca un procedimiento predefinido en el sitio
A. El procedimiento se ejecuta adecuadamente y luego devuelve los resultados a P.
Alternativamente, el proceso P puede enviar un mensaje al sitio A. El sistema operativo

del sitio A crea entonces un nuevo proceso Q cuya función es llevar a cabo la tarea
designada. Cuando el proceso Q completa su ejecución, devuelve el resultado necesario a
P a través del sistema de mensajes. En este esquema, el proceso P puede ejecutarse

concurrentemente con el proceso Q. De hecho, puede tener varios procesos ejecutándose
concurrentemente en varios sitios.
Cualquiera de los dos métodos podría utilizarse para acceder a varios archivos (o trozos de
archivos) que residen en varios sitios. Una RPC podría resultar en la invocación de otra
RPC o incluso en la transferencia de mensajes a otro sitio. Del mismo modo, el proceso Q
podría, durante su ejecución, enviar un mensaje a otro sitio, que a su vez crearía otro
proceso. Este proceso podría enviar un mensaje de vuelta a Q o repetir el ciclo.
Migración de procesos
Una extensión lógica de la migración informática es la migración de procesos. Cuando un

proceso se envía para su ejecución, no siempre se ejecuta en el sitio en el que se inicia. El
proceso completo, o parte de él, puede ejecutarse en diferentes sitios. Este esquema
puede utilizarse por varias razones:
Equilibrado de carga
Los procesos, o subprocesos, pueden distribuirse entre los sitios para igualar la carga de
trabajo.
Aceleración de los cálculos
Si un único proceso puede dividirse en varios subprocesos que pueden ejecutarse

simultáneamente en distintos sitios o nodos, puede reducirse el tiempo total de ejecución
del proceso.
Preferencias hardware
El proceso puede tener características que lo hagan más adecuado para su ejecución en
algún procesador especializado, como la inversión de matrices en una GPU, que en un
microprocesador.
Preferencias software
El proceso puede requerir un software que sólo está disponible en un sitio concreto y, o
bien el software no puede trasladarse, o bien es menos costoso trasladar el proceso.
Acceso a datos
Al igual que en la migración de cálculos, si los datos que se utilizan en el cálculo son
numerosos, puede ser más eficiente hacer que un proceso se ejecute a distancia, por

ejemplo, en un servidor que aloje una gran base de datos, que transferir todos los datos y
ejecutar el proceso localmente.
Utilizamos dos técnicas complementarias para trasladar procesos en una red informática.
En la primera, el sistema puede intentar ocultar al cliente que el proceso ha migrado. Así,
el cliente no necesita codificar explícitamente su programa para realizar la migración. Este
método suele emplearse para lograr el equilibrio de la carga y el aumento de la velocidad
de cálculo entre sistemas homogéneos, ya que no necesitan que el usuario les ayude a
ejecutar programas a distancia. El otro enfoque consiste en permitirle, o exigirle, al
usuario que especifique explícitamente cómo debe migrar el proceso. Este método suele
emplearse cuando el proceso debe trasladarse para satisfacer una preferencia de
hardware o software.
Probablemente se habrá dado cuenta de que la WWW tiene muchos aspectos de un

entorno informático distribuido. Ciertamente, proporciona migración de datos (entre un
servidor web y un cliente web). También permite la migración de cálculos. Por ejemplo, un
cliente web puede activar una operación de base de datos en un servidor web. Por último,
con Java, Javascript y lenguajes similares, ofrece una forma de migración de procesos: Los
applets Java y los scripts Javascript se envían del servidor al cliente, donde se ejecutan. Un
sistema operativo en red proporciona la mayoría de estas funciones, pero un sistema
operativo distribuido las hace fluidas y fácilmente accesibles. El resultado es un sistema
potente y fácil de usar, una de las razones del enorme crecimiento de la WWW.
Características de diseño de los sistemas operativos distribuidos

Los diseñadores de un sistema distribuido deben tener en cuenta varios desafíos de
diseño. El sistema debe ser robusto para que pueda soportar fallas. También debe ser
transparente para los usuarios, tanto en lo que se refiere a la ubicación de los archivos
como a la movilidad de los usuarios. Por último, el sistema debe ser escalable para
permitir la adición de más potencia de cálculo, más almacenamiento o más usuarios. A
continuación, presentamos brevemente estas cuestiones.

Robustez
Un sistema distribuido puede sufrir varios tipos de fallas de hardware. La falla de un

enlace, un host o un sitio y la pérdida de un mensaje son los tipos más comunes. Para que
el sistema sea robusto, hay que detectar cualquiera de estas fallas, reconfigurar el sistema
para que el cómputo pueda continuar y recuperarse cuando se repare la falla. Un sistema
puede ser tolerante a fallas en el sentido de que puede tolerar un determinado nivel de
fallas y seguir funcionando con normalidad. El grado de tolerancia a fallas depende del
diseño del sistema distribuido y de la falla específica. Obviamente, una mayor tolerancia a
fallas es mejor.
Utilizamos el término tolerancia a fallas en un sentido amplio. Las fallas de comunicación,

ciertas fallas de las máquinas, las caídas de los dispositivos de almacenamiento y la
degradación de los medios de almacenamiento deben ser tolerados hasta cierto punto.
Un sistema tolerante a fallas debe seguir funcionando, quizás de forma degradada,
cuando se enfrenta a tales fallas. La degradación puede afectar al rendimiento, a la
funcionalidad o a ambos. Sin embargo, debe ser proporcional a las fallas que la causaron.
Un sistema que se detiene cuando falla sólo uno de sus componentes no es tolerante a
fallas.
Por desgracia, la tolerancia a fallas puede ser difícil y costosa de implantar. En la capa de
red, se necesitan múltiples rutas de comunicación redundantes y dispositivos de red como
conmutadores y enrutadores para evitar una falla de comunicación. Una falla en el
almacenamiento puede causar la pérdida del sistema operativo, las aplicaciones o los
datos. Las unidades de almacenamiento pueden incluir componentes de hardware
redundantes que se sustituyen automáticamente entre sí en caso de falla. Además, los
sistemas RAID pueden garantizar el acceso continuo a los datos incluso en caso de falla de
uno o varios dispositivos de almacenamiento.
Detección de fallas
En un entorno sin memoria compartida, generalmente no podemos diferenciar entre falla

de enlace, falla de sitio, falla de host y pérdida de mensajes. Normalmente sólo podemos
detectar que se ha producido una de estas fallas. Una vez que se ha detectado una falla,
se debe tomar la acción apropiada. Qué acción es apropiada depende de la aplicación.
Para detectar fallas en enlaces y sitios, utilizamos un procedimiento de contacto.

Supongamos que los sitios A y B tienen un enlace físico directo entre ellos. A intervalos
fijos, los sitios se envían mutuamente un mensaje Estoy funcionando. Si el sitio A no recibe

este mensaje en un periodo de tiempo predeterminado, puede asumir que el sitio B ha
fallado, que el enlace entre A y B ha fallado o que el mensaje de B se ha perdido. En este
punto, el sitio A tiene dos opciones. Puede esperar otro periodo de tiempo para recibir un
mensaje Estoy funcionando de B, o puede enviar un mensaje ¿Estás funcionando? a B.
Si pasa el tiempo y el sitio A todavía no ha recibido un mensaje Estoy funcionando, o si el

sitio A ha enviado un mensaje ¿Estás funcionando? y no ha recibido respuesta, se puede
repetir el procedimiento. De nuevo, la única conclusión que el sitio A puede sacar con
seguridad es que se ha producido algún tipo de falla.
El sitio A puede intentar diferenciar entre una falla de enlace y una falla de sitio enviando
un mensaje ¿Estás funcionando? a B por otra ruta, si existe. Cuando B recibe este
mensaje, responde inmediatamente de forma positiva. Esta respuesta positiva le dice a A
que B está conectado y que la falla está en el enlace directo entre ellos. Como no sabemos
de antemano cuánto tardará el mensaje en viajar de A a B y viceversa, debemos utilizar un
esquema de tiempo de espera. En el momento en que A envía el mensaje ¿Estás
funcionando?, especifica un intervalo de tiempo durante el cual está dispuesto a esperar
la respuesta de B. Si A recibe el mensaje de respuesta dentro de ese intervalo de tiempo,
entonces puede concluir con seguridad que B está funcionando. Sin embargo, si no es así,
es decir, si se vence ese intervalo de tiempo, entonces A sólo puede concluir que se ha
producido una o más de las siguientes situaciones:
 El sitio B está caído.

 El enlace directo, si existe, de A a B está caído.
 La ruta alternativa de A a B está caída.
 El mensaje se ha perdido. Aunque el uso de un protocolo de transporte fiable
como TCP debería eliminar esta preocupación.
El sitio A no puede, sin embargo, determinar cuál de estos eventos ha ocurrido.
Reconfiguración
Supongamos que el sitio A ha descubierto, mediante el mecanismo que acabamos de

describir, que se ha producido una falla. Entonces debe iniciar un procedimiento que
permita al sistema reconfigurarse y continuar su modo normal de funcionamiento.
 Si ha fallado un enlace directo de A a B, esta información debe transmitirse a todos

los sitios del sistema, para que las distintas tablas de encaminamiento puedan
actualizarse en consecuencia.

 Si el sistema cree que un sitio ha fallado, porque ya no se puede llegar a ese sitio,
entonces todos los sitios del sistema deben ser notificados, para que ya no
intenten utilizar los servicios del sitio que ha fallado. La falla de un sitio que sirve
de coordinador central para alguna actividad, como la detección de bloqueos,
requiere la elección de un nuevo coordinador. Nótese que, si el sitio no ha fallado,
es decir, si está activo, pero no se puede llegar a él, entonces podemos tener la
indeseable situación en la que dos sitios sirven de coordinador. Cuando la red está
particionada, los dos coordinadores, cada uno para su propia partición, pueden
iniciar acciones conflictivas. Por ejemplo, si los coordinadores son responsables de
implementar la exclusión mutua, podemos tener una situación en la que dos
procesos se estén ejecutando simultáneamente en sus secciones críticas.
Recuperación de fallas
Cuando se repara un enlace o sitio que ha fallado, debe integrarse en el sistema con
elegancia y sin problemas.
 Supongamos que un enlace entre A y B ha fallado. Cuando se repara, tanto A como

B deben ser notificados. Esta notificación puede realizarse repitiendo
continuamente el procedimiento de contacto descrito anteriormente.
 Supongamos que el sitio B ha fallado. Cuando se recupere, debe notificar a todos
los demás sitios que ha vuelto a funcionar. Es posible que el sitio B tenga que
recibir información de los otros sitios para actualizar sus tablas locales. Por
ejemplo, puede necesitar información de la tabla de enrutamiento, una lista de los
sitios que están caídos, mensajes no entregados, un registro de transacciones no
ejecutadas y correo. Si el sitio no ha fallado, sino que simplemente no puede ser
alcanzado, entonces todavía necesita esta información.
Transparencia
Hacer que los múltiples procesadores y dispositivos de almacenamiento de un sistema

distribuido sean transparentes para los usuarios ha sido un reto clave para muchos
diseñadores. Idealmente, un sistema distribuido debería parecer a sus usuarios como un
sistema convencional centralizado. La interfaz de usuario de un sistema distribuido
transparente no debería distinguir entre recursos locales y remotos. Es decir, los usuarios
deberían poder acceder a los recursos remotos como si fueran locales, y el sistema

distribuido debería encargarse de localizar los recursos y organizar la interacción
adecuada.
Otro aspecto de la transparencia es la movilidad de los usuarios. Sería conveniente

permitir a los usuarios conectarse a cualquier máquina del sistema en lugar de obligarles a
utilizar una máquina específica. Un sistema distribuido transparente facilita la movilidad
del usuario trasladando su entorno, por ejemplo, su directorio personal, a cualquier
máquina en la que se conecte. Protocolos como LDAP proporcionan un sistema de
autenticación para usuarios locales, remotos y móviles. Una vez completada la
autenticación, facilidades como la virtualización de equipos personales permiten a los
usuarios ver sus sesiones en instalaciones remotas.
Escalabilidad
Otra cuestión es la escalabilidad, es decir, la capacidad de un sistema para adaptarse a una

mayor carga de servicio. Los sistemas tienen recursos limitados y pueden saturarse por
completo ante un aumento de la carga. Por ejemplo, con respecto a un sistema de
archivos, la saturación se produce cuando la CPU de un servidor funciona a una tasa de
utilización elevada o cuando las solicitudes de E/S de los discos desbordan el subsistema
de E/S. La escalabilidad es una propiedad relativa, pero puede medirse con precisión. Un
sistema escalable reacciona mejor al aumento de la carga que uno no escalable. En primer
lugar, su rendimiento se degrada más moderadamente y, en segundo lugar, sus recursos
alcanzan un estado de saturación más tarde. Sin embargo, ni siquiera un diseño perfecto
puede adaptarse a una carga cada vez mayor. Añadir nuevos recursos puede resolver el
problema, pero puede generar una carga indirecta adicional sobre otros recursos; por
ejemplo, añadir máquinas a un sistema distribuido puede atascar la red y aumentar las
cargas de servicio. Peor aún, ampliar el sistema puede exigir costosas modificaciones de
diseño. Un sistema escalable debe tener la posibilidad de crecer sin estos problemas. En
un sistema distribuido, la capacidad de escalar con elegancia es de especial importancia,
ya que ampliar una red añadiendo nuevas máquinas o interconectando dos redes es algo
habitual. En resumen, un diseño escalable debe soportar una gran carga de servicio,
adaptarse al crecimiento de la comunidad de usuarios y permitir una integración sencilla
de los recursos añadidos.
La escalabilidad está relacionada con la tolerancia a fallas, comentada anteriormente. Un

componente muy cargado puede paralizarse y comportarse como un componente
defectuoso. Además, trasladar la carga de un componente defectuoso al de reserva de ese

componente puede saturar a este último. En general, disponer de recursos de reserva es
esencial para garantizar la fiabilidad, así como para gestionar los picos de carga con
elegancia. Así, los múltiples recursos de un sistema distribuido representan una ventaja
inherente, ya que confieren al sistema un mayor potencial de tolerancia a fallas y
escalabilidad. Sin embargo, un diseño inadecuado puede ocultar este potencial. Las
consideraciones de tolerancia a fallas y escalabilidad exigen un diseño que demuestre la
distribución del control y los datos.
La escalabilidad también puede estar relacionada con esquemas de almacenamiento

eficientes. Por ejemplo, muchos proveedores de almacenamiento en la nube utilizan la
compresión o la deduplicación1 para reducir la cantidad de almacenamiento utilizado. La
compresión reduce el tamaño de un archivo. Por ejemplo, un archivo zip puede generarse
a partir de un archivo o archivos ejecutando un comando zip, que ejecuta un algoritmo de
compresión sin pérdidas sobre los datos especificados. La compresión sin pérdidas
permite reconstruir perfectamente los datos originales a partir de los datos comprimidos.
El resultado es un archivo más pequeño que el archivo sin comprimir. Para restaurar el
archivo a su estado original, el usuario ejecuta algún tipo de comando de descompresión
sobre el archivo comprimido. La deduplicación pretende reducir los requisitos de
almacenamiento de datos eliminando los datos redundantes. Con esta tecnología, sólo se
almacena una instancia de datos en todo un sistema, incluso en los datos que pertenecen
a varios usuarios. Tanto la compresión como la deduplicación pueden realizarse a nivel de
archivo o de bloque, y pueden utilizarse conjuntamente. Estas técnicas pueden integrarse
automáticamente en un sistema distribuido para comprimir la información sin que los
usuarios tengan que emitir comandos explícitos, ahorrando así espacio de
almacenamiento y posiblemente reduciendo los costos de comunicación en red sin añadir
complejidad al usuario.
Modelos de sistemas operativos distribuidos

Todo modelo de un sistema distribuido trata sobre el contenido de sus partes y las
relaciones que existan entre ellas. Los más conocidos son el modelo cliente-servidor y el
modelo de procesos “de igual a igual” (peer to peer). Los sistemas distribuidos, presentan
ciertas dificultades que los diseñadores deben tener bien en cuenta, entre las cuales se
destacan:
1
La deduplicación de datos es un proceso que elimina las copias excesivas de los datos y reduce
significativamente los requisitos de capacidad de almacenamiento.

Modos de utilización muy variables
Los componentes de los sistemas están sujetos a grandes variaciones en la carga de

trabajo.
Amplio rango de entorno
Normalmente deberán coexistir hardware, sistemas operativos y entornos de red

diferentes.
Problemas internos
Relojes no sincronizados, actualizaciones de datos conflictivas, muchas formas de falla en

hardware y software, implicando a componentes individuales del sistema.
Amenazas externas
Están expuestas a ataques a la integridad, al secreto de los datos y a la denegación del

servicio.
El término arquitectura de software se refiere a la estructuración del software como capas

o módulos en función de los servicios ofrecidos y solicitados entre procesos localizados en
el mismo o en diferentes computadores.
La plataforma está conformada por la conjunción del hardware y el sistema operativo. Se

pueden mencionar como ejemplo diferentes plataformas como:
 Windows para Intel x86

 Sun OS para SunSparc
 Mac OS para Power PC
 Linux para Intel x86
Modelo cliente-servidor
Como sugiere el término, un entorno cliente/servidor está poblado por clientes y

servidores. Las máquinas cliente son generalmente computadores personales o estaciones
de trabajo que proporcionan una interfaz muy fácil de usar al usuario final. La estación
basada en el cliente suele presentar el tipo de interfaz gráfica más cómoda para los
usuarios, incluyendo el uso de ventanas y mouse. Las aplicaciones basadas en el cliente
están adaptadas para facilitar su uso e incluyen herramientas tan familiares como la hoja
de cálculo.

Cada servidor del entorno cliente/servidor proporciona un conjunto de servicios
compartidos a los clientes. El tipo de servidor más común actualmente es el servidor de
bases de datos, que suele controlar una base de datos relacional. El servidor permite que
muchos clientes compartan el acceso a la misma base de datos y permite el uso de un
sistema de computación de alto rendimiento para gestionar la base de datos.
Además de los clientes y los servidores, el tercer ingrediente esencial del entorno
cliente/servidor es la red. La computación cliente/servidor es típicamente una
computación distribuida. Los usuarios, las aplicaciones y los recursos se distribuyen en
respuesta a las necesidades de la empresa y están conectados por una única LAN o WAN o
Internet.
Es la interacción de procesos clientes que invocan y procesos servidores que responden,

en computadoras separadas y con el fin de acceder a recursos compartidos que los
clientes gestionan. Los procesos servidores pueden ser a su vez clientes de otros
servidores. La siguiente figura representa un ejemplo de modelo cliente-servidor.
¿Qué requisitos de diseño deberían presentar las arquitecturas distribuidas? ¿En qué se
diferencia la configuración cliente/servidor de otras soluciones de procesamiento
distribuido? Existen una serie de características que, juntas, diferencian a la filosofía
cliente/servidor de otros tipos de procesamiento distribuido:
 Es imperativo que los usuarios tengan aplicaciones de fácil manejo en sus sistemas.
Esto da al usuario un gran control sobre el tiempo y el estilo de uso del
computador y da a los gestores del departamento la capacidad de responder a sus
necesidades locales.
 Aunque las aplicaciones están dispersas, se hace hincapié en la centralización de
las bases de datos corporativas y de muchas funciones de gestión y utilidad de la
red. Esto permite a la dirección de la empresa mantener el control general de la
inversión total en sistemas de computación e información y proporcionar
interoperabilidad para que los sistemas estén vinculados entre sí. Al mismo

tiempo, libera a los departamentos y sucursales de gran parte de los gastos de
mantenimiento de sofisticadas instalaciones basadas en computadores, pero les
permite elegir casi cualquier tipo de máquina e interfaz que necesiten para
acceder a los datos y la información.
 Tanto las organizaciones de usuarios como los proveedores apuestan por sistemas
abiertos y modulares. Esto significa que el usuario tiene más opciones a la hora de
seleccionar productos y de mezclar equipos de varios proveedores.
 La red es fundamental para el funcionamiento. Por ello, la gestión y la seguridad de
la red tienen una alta prioridad en la organización y el funcionamiento de los
sistemas de información.
La característica fundamental de una arquitectura cliente/servidor es la distribución de las

tareas de la aplicación entre el cliente y el servidor. Tanto en el cliente como en el
servidor, por supuesto, el software básico es el sistema operativo que ejecuta sobre el
hardware de la plataforma. La plataforma y el sistema operativo del cliente y del servidor
pueden ser diferentes. De hecho, pueden existir diferentes plataformas de clientes y
sistemas operativos y diferentes plataformas de servidor en un mismo entorno. Siempre
que los clientes y los servidores compartan los mismos protocolos de comunicación y
soporten las mismas aplicaciones, estas diferencias de bajo nivel no son relevantes.
Quien permite que interactúen el cliente y el servidor es el software de comunicaciones. El

principal ejemplo de este software es TCP/IP. Por supuesto, el objetivo de todo este
software de soporte, tanto comunicaciones como sistema operativo, es proporcionar las
bases para las aplicaciones distribuidas. De forma ideal, las funciones que realiza una
aplicación se pueden dividir entre el cliente y el servidor, de manera que se optimice el
uso de los recursos. En algunos casos, dependiendo de las necesidades de la aplicación, la
mayor parte del software de aplicación ejecuta en el servidor, mientras que, en otros
casos, la mayor parte de la lógica de la aplicación está situada en el cliente.
Un factor esencial en el éxito de un entorno cliente/servidor es la forma en que el usuario

interactúa con el sistema. De esta forma, es decisivo el diseño de la interfaz de usuario en
la máquina cliente. En la mayor parte de los sistemas cliente/servidor, se hace mucho
énfasis en proporcionar una interfaz gráfica de usuario (GUI) que sea fácil de usar, fácil de
aprender y, a la vez, potente y flexible. De esta forma, podemos pensar en el módulo de
servicios de presentación en la parte del cliente, como el responsable de proporcionar una
interfaz de fácil manejo a las aplicaciones distribuidas disponibles en el entorno.

Para mostrar el concepto de distribuir la lógica de aplicación entre el cliente y el servidor,
tenemos como ejemplo a las que hacen uso de bases de datos relacionales. En este
entorno, el servidor es básicamente un servidor de base de datos. La interacción entre el
cliente y el servidor se realiza a través transacciones, en las que el cliente realiza una
petición a la base de datos y recibe una respuesta.
El servidor es responsable del mantenimiento de la base de datos, para lo que se requiere

un complejo sistema gestor de base de datos. En las máquinas clientes se pueden situar
diferentes aplicaciones que hacen uso de la base de datos. Lo que une al cliente y al
servidor es el software que permite que el cliente haga peticiones para acceder al servidor
de la base de datos. Un ejemplo es el lenguaje estructurado de consultas (SQL).
Toda la lógica de aplicación, es decir el software para el análisis de datos, está en la parte
del cliente, mientras que el servidor sólo se preocupa de la gestión de la base de datos.
Que esta configuración sea la apropiada, depende del estilo y del propósito de la
aplicación. Por ejemplo, supongamos que el propósito general es proporcionar acceso on-
line para la búsqueda de registros. Supongamos que el servidor está manteniendo una
base de datos con 1 millón de registros, y el cliente quiere realizar una búsqueda que
devolverá cero, uno, o como mucho unos pocos registros. El usuario podría buscar estos
registros utilizando una serie de criterios de búsqueda, por ejemplo, registros anteriores a
2019; registros de individuos de Córdoba; registros de un determinado evento o
característica, etc. Una consulta inicial del cliente puede llevar asociada la respuesta de
que hay 100.000 registros que satisfacen estos criterios. El usuario añade información
adicional y vuelve a realizar la consulta. Esta vez, la respuesta indica que hay 1000 posibles
registros. Finalmente, el cliente manda una tercera consulta con más información. El
resultado de la búsqueda lleva a un solo registro, que se le devuelve al cliente.
La aplicación anterior es conveniente para un entorno cliente/servidor por dos razones:
1. Hay un enorme trabajo de búsqueda y ordenamiento en la base de datos. Esto

requiere un gran disco o un banco de discos, una CPU con mucha velocidad y una
potente arquitectura de E/S. Esta potencia y capacidad no es necesaria, y es
demasiado cara, para una estación de trabajo o computador de un usuario.
2. Sería demasiado costoso para la red mover el millón de registros al cliente para
que éste realice la búsqueda. Por tanto, no es suficiente que el servidor sea capaz
de recuperar registros de la base de datos para el cliente; el servidor necesita tener
una lógica que le permita realizar búsquedas para el cliente.

Ahora consideremos el siguiente escenario, que tiene la misma base de datos con 1 millón
de registros. En este caso, la consulta hace que se transmitan 300.000 registros por la red.
Esto podría suceder si, por ejemplo, el usuario deseara encontrar el valor total o medio de
algunos campos de muchos registros, o incluso de la base de datos completa.
Claramente, este último escenario no es admisible. Una solución a este problema, que
mantendría la arquitectura cliente/servidor con todos sus beneficios, es trasladar parte de
la lógica de aplicación al servidor. Es decir, se puede equipar al servidor con lógica de
aplicación que realice análisis de datos además de recepción y búsqueda de datos.
Dentro del marco general cliente/servidor, hay una serie de implementaciones que
dividen el trabajo entre el cliente y el servidor de diferente manera. Aunque son posibles
otras divisiones y, para otra clase de aplicaciones, se podrían realizar caracterizaciones
diferentes, podemos definir las cuatro clases siguientes:
Procesamiento basado en el host
El procesamiento basado en el host no es una verdadera computación cliente/servidor tal

y como se entiende el término. Se refiere a los entornos mainframe tradicionales en los
que virtualmente todo el procesamiento se realiza en el host central. A menudo, la
interfaz de usuario se realiza a través de un interfaz tonto. Incluso si el usuario está
empleando una computadora, la estación del usuario se limita al papel de emulador de
terminal.
Procesamiento basado en el servidor
La clase más básica de configuración cliente/servidor es en la que el cliente es el principal

responsable de proporcionar la interfaz gráfica de usuario, mientras que prácticamente
todo el procesamiento se realiza en el servidor. Esta configuración es típica de cuando se
comienza a utilizar el entorno cliente/servidor, especialmente en sistemas a nivel de
departamento. El razonamiento detrás de estas configuraciones es que la estación de
trabajo del usuario es mejor para proporcionar una interfaz de usuario de fácil manejo, y
que las bases de datos y las aplicaciones se pueden mantener más fácilmente en sistemas
centrales. Aunque el usuario obtiene la ventaja de una mejor interfaz, este tipo de
configuraciones no suele generar grandes ventajas en productividad, ni cambios
fundamentales en las funciones de negocio soportadas por el sistema.

Procesamiento basado en el cliente
En el otro extremo, prácticamente todo el procesamiento se puede realizar en el cliente,

con la excepción de las rutinas de validación de datos y otras funciones de la lógica de la
base de datos que se pueden realizar mejor en el servidor. Generalmente, alguna de las
funciones más sofisticadas de la lógica de la base de datos se realiza en la parte cliente.
Esta arquitectura es, quizás, el enfoque cliente/servidor más común actualmente en uso.
Permite a los usuarios el uso de aplicaciones adaptadas a las necesidades locales.
Procesamiento cooperativo
En una configuración de procesamiento cooperativo, el procesamiento de la aplicación se

realiza de forma óptima, beneficiándose de las máquinas cliente y servidora y de la
distribución de los datos. Esta configuración es más compleja de configurar y mantener,
pero, a largo plazo, puede proporcionar mayor productividad a los usuarios y mayor
eficiencia de red que otros enfoques cliente/servidor.
Las configuraciones en que gran parte de la carga está en la parte cliente, es decir los
casos de procesamiento basado en el cliente y procesamiento cooperativo, modelo
denominado cliente pesado (fat client) se ha popularizado gracias a herramientas de
desarrollo de aplicaciones como PowerBuilder de Sybase Inc. o SQL Windows de Gupta
Corp. Las aplicaciones desarrolladas con estas herramientas suelen ser departamentales y
soportan entre 25 y 150 usuarios. La principal ventaja de este modelo es que se beneficia
de la potencia de los computadores personales, descargando a los servidores y
haciéndolos más eficientes y menos propensos a ser el cuello de botella.
Existen, sin embargo, varias desventajas en la estrategia de los clientes pesados. Añadir
nuevas funcionalidades suele sobrecargar la capacidad de los computadores personales,
forzando a las compañías a actualizarse. Si el modelo sale del departamento y se
incorporan muchos usuarios, la compañía debe instalar redes locales (LAN) de alta
capacidad para dar soporte al gran número de transmisiones entre los servidores ligeros y
los clientes pesados. Por último, es difícil mantener, actualizar o reemplazar aplicaciones
distribuidas entre decenas o centenas de computadores. Otro enfoque es el denominado
enfoque de cliente ligero. Este enfoque imita al enfoque tradicional centralizado del host y
es, a menudo, la ruta de migración para pasar las aplicaciones corporativas de los
mainframes a un entorno distribuido.

La arquitectura tradicional cliente/servidor implica normalmente dos niveles o capas: la
capa del cliente y la capa del servidor. Pero también es habitual una arquitectura de tres
capas en la que el software de la aplicación se distribuye entre tres tipos de máquinas:
una máquina de usuario, un servidor en la capa central, y un servidor en segundo plano
(backend).
La máquina de usuario es la máquina cliente que hemos estado viendo y que, en el

modelo de tres capas, normalmente es un cliente ligero. Las máquinas de la capa central
son normalmente una pasarela entre los clientes ligeros y varios servidores de bases de
datos en segundo plano. Las máquinas de la capa central pueden convertir protocolos y
cambiar de un tipo de consulta de base de datos a otra. Además, las máquinas de la capa
central pueden mezclar, o integrar, los resultados de diferentes fuentes de datos.
Finalmente, pueden servir como pasarela entre las aplicaciones de computadores
personales y las aplicaciones de los servidores en segundo plano, mediando entre los dos
mundos. La interacción entre el servidor de la capa central y el servidor en segundo plano
también sigue el modelo cliente/servidor. De esta forma, el sistema de la capa intermedia
actúa de cliente y de servidor.
Asimismo, cuando se utiliza un servidor de archivos, el rendimiento de la E/S de archivos

se puede degradar en comparación con el acceso local a archivos, debido a los retrasos
generados por la red. Para reducir este problema de rendimiento, los sistemas
individuales pueden utilizar caché de archivos para almacenar los registros de los archivos
a los que se ha accedido recientemente. Debido al principio de localidad, el uso de una
caché local de archivos debería reducir el número de accesos necesarios al servidor
remoto. Cuando un proceso realiza un acceso a un archivo, la petición se presenta
primero a la caché de la estación de trabajo del proceso. Si no es satisfactoria, la petición
se pasa al disco local, si el archivo está allí almacenado, o al servidor de archivos, donde el
archivo está almacenado. En el servidor, se pregunta primero a la caché del servidor, y si
no está allí, se accede al disco del servidor. Este enfoque de doble caché se utiliza para
reducir el tráfico de comunicación (caché de cliente) y la E/S de disco (caché de servidor).
Cuando la caché contiene siempre copias exactas de los datos remotos, decimos que las
cachés son consistentes. Es posible que las cachés se vuelvan inconsistentes cuando se
cambian los datos remotos y no se descartan las correspondientes copias locales en la
caché. Esto puede suceder si un cliente modifica un archivo que también está en la caché
de otro cliente. El problema es doble. Si el cliente adopta la política de escribir
inmediatamente en el servidor los cambios de un archivo, cualquier otro cliente que tenga

una copia en la caché de la parte del archivo que ha cambiado, tendrá datos antiguos. El
problema es incluso peor si el cliente retrasa la escritura en el servidor. En este caso, el
servidor tendrá una versión antigua del archivo y las nuevas peticiones de lectura al
servidor podrían obtener datos antiguos. El problema de mantener actualizadas las copias
locales de caché es conocido como el problema de la consistencia de caché.
El mecanismo más sencillo para la consistencia de caché es utilizar técnicas de bloqueo de

archivos para evitar accesos simultáneos a un archivo por más de un cliente. Esto
garantiza la consistencia a costa de rendimiento y flexibilidad. Un mecanismo más
eficiente es el siguiente. Cualquier número de procesos remotos pueden abrir el archivo
para lectura y almacenarlo en su propia caché. Pero cuando una solicitud de apertura de
archivo pide accesos de escritura y otros procesos tienen el archivo abierto con acceso de
lectura, el servidor realiza dos acciones. Primero, notifica al proceso que escribe que,
aunque puede mantener una copia local, debe mandar al servidor todos los bloques que
se cambien inmediatamente. Puede haber como mucho uno de estos clientes. Segundo, el
servidor notifica a todos los procesos lectores que tienen el archivo abierto que el archivo
ya no se puede mantener en caché.
Middleware
Para lograr los verdaderos beneficios del mecanismo cliente/servidor, los desarrolladores
deben tener un conjunto de herramientas que proporcionen una manera y estilo de
acceso uniforme a los recursos del sistema a través de todas las plataformas. Esto
permitirá a los programadores construir aplicaciones que no sólo parezcan iguales en
todos los computadores personales y estaciones de trabajo, sino que utilicen el mismo
método para acceder a los datos, independientemente de la localización de estos. La
forma más común de cumplir estos requisitos es a través del uso de interfaces de
programación y protocolos estándares entre la aplicación y el software de comunicaciones
y el sistema operativo. Estas interfaces de programación y protocolos se denominan
middleware.
Hay diversos paquetes de middleware, que varían desde los muy sencillos a los muy
complejos. Lo que tienen todos en común es la capacidad de esconder la complejidad y
disparidad de los diferentes protocolos de red y sistemas operativos. De esta forma un
usuario puede fijar una estrategia middleware particular y montar equipos de varios
proveedores que soporten esa estrategia. El papel exacto del middleware dependerá del
estilo de computación cliente/servidor utilizado.

El propósito básico del middleware es permitir a una aplicación o usuario en el cliente
acceder a una variedad de servicios en el servidor sin preocuparse de las diferencias entre
los servidores. Para ver un área específica de aplicación, el lenguaje estructurado de
consultas (SQL) se supone que proporciona un acceso estándar a una base de datos
relacional por un usuario o aplicación local o remoto. Sin embargo, muchos proveedores
de bases de datos relacionales, aunque soportan SQL, han añadido sus propias
extensiones. Esto permite a los proveedores diferenciar sus productos, pero también crea
potenciales incompatibilidades.
Como ejemplo, consideremos un sistema distribuido utilizado para dar soporte, entre
otras cosas, al departamento de personal. Los datos básicos del empleado, tales como su
nombre y dirección, pueden estar almacenados en una base de datos Gupta, mientras que
la información de su salario puede estar en una base de datos Oracle. Cuando un usuario
en el departamento de personal quiere acceder a un registro en particular, no se quiere
preocupar de qué tipo de base de datos contiene los registros.
El middleware proporciona una capa de software que permite un acceso uniforme a estos
sistemas diferentes. Esta capa de software tiene como objetivo enmascarar la
heterogeneidad de las plataformas y proporcionar un modelo de programación
conveniente para los programadores de aplicaciones. Proporciona bloques para construir
componentes de software que puedan trabajar con otros sistemas distribuidos. Entre
otras cosas mejora la comunicación entre programas de aplicación soportando:
 Procedimientos de invocación remota

 Comunicación entre un grupo de procesos
 Notificación de eventos
 Replicación de datos compartidos
 Transmisión de datos multimedia en tiempo real
El sistema distribuido completo se puede ver como un conjunto de aplicaciones y recursos

disponibles para los usuarios. Los usuarios no necesitan preocuparse de la localización de
los datos o de la localización de las aplicaciones. Todas las aplicaciones operan sobre una
interfaz de programación de aplicaciones (API) uniforme. El middleware, que se sitúa
entre todas las plataformas cliente y servidor, es el responsable de guiar las peticiones al
servidor apropiado. Aunque hay una gran variedad de productos middleware, todos ellos
se basan usualmente en uno o dos mecanismos: el paso de mensajes y las llamadas a
procedimiento remoto.

Los ejemplos más utilizados de middleware son paquetes de llamadas a procedimientos
como RPC de SUN, ISIS o IV9000 de BULL. Entre los productos y estándares de middleware
orientado a objetos están:
 CORBA (Common Object Request Broker Architecture De OMG).

 Invocación a objetos remotos en JAVA (RMI, Remote Method Invocation)
 Modelo común de objetos distribuidos de Microsoft (DCOM Distributed Common
Objects Model)
 Modelo de referencia para proceso distribuido abierto de la ISO/ITU-T (RM-ODP
Referente Modelfor Open Distributed Processing)
Respecto de las limitaciones del middleware se puede decir que, aunque ha conseguido
mucho en la simplificación de la programación en los sistemas distribuidos, todavía
algunos aspectos de confiabilidad necesitan soporte del nivel de aplicación. Los programas
distribuidos requieren comprobaciones, mecanismos de corrección de errores y medidas
de seguridad, donde algunas de las cuales necesitan datos de direcciones de la capa de
aplicación y no les basta con la de middleware.
La arquitectura de un sistema es su estructura, en función de sus componentes

especificados individualmente; la cual se diseñará con el objeto de asegurar que la misma
satisfaga demandas actuales y futuras sobre el sistema. Para poder analizar los modelos
arquitectónicos se pueden clasificar los procesos de sistemas distribuidos en:
 Servidores
 Clientes e iguales
Los modelos arquitectónicos que se detallarán pueden proporcionar sólo una versión
simplificada de los patrones de distribución más importantes. Seguidamente se presentan
los principales modelos arquitectónicos sobre los que se basa la división de
responsabilidades de los componentes del sistema (aplicaciones, servidores y otros
procesos).
Sistemas distribuidos sincrónicos
Un sistema distribuido sincrónico está definido por los siguientes límites:
 Tiempo de ejecución de cada etapa definido por su límite inferior y superior que
debe ser suficientemente conocido.
 Cada mensaje transmitido debe tener un tiempo límite conocido.

 Cada proceso tiene un reloj local, cuya tasa de error o deriva debe ser menor a un
límite conocido.
Sistemas distribuidos asincrónicos
Un sistema distribuido asincrónico es aquél sobre el cual no existen limitaciones de:
 Velocidad de procesamiento.
 Retardo de transmisión de mensajes.
 Tasas de error o derivas de relojes.
El modelo asincrónico es muy útil y aplicable en los sistemas distribuidos, un ejemplo de

este modelo es Internet, aunque para ciertas aplicaciones como por ejemplo las
multimediales, no es posible utilizar este modelo.
Sistemas de archivos distribuidos

Aunque la Web es el sistema distribuido predominante en la actualidad, no es el único.
Otro uso importante y popular de la informática distribuida son los sistemas de archivos
distribuidos, o DFS (Distributed File Systems).
Para explicar la estructura de un DFS, necesitamos definir los términos servicio, servidor y
cliente en el contexto DFS. Un servicio es una entidad de software que se ejecuta en una o
más máquinas y proporciona un tipo particular de función a los clientes. Un servidor es el
software de servicio que se ejecuta en una única máquina. Un cliente es un proceso que
puede invocar un servicio utilizando un conjunto de operaciones que forman su interfaz
de cliente. A veces se define una interfaz de nivel inferior para la interacción real entre
máquinas; es la interfaz entre máquinas.
Utilizando esta terminología, decimos que un sistema de archivos proporciona servicios de

archivo a los clientes. Una interfaz de cliente para un servicio de archivos está formada
por un conjunto de operaciones de archivo primitivas, como crear un archivo, eliminar un
archivo, leer de un archivo y escribir en un archivo. El principal componente de hardware
que controla un servidor de archivos es un conjunto de dispositivos locales de
almacenamiento secundario, normalmente, discos duros o unidades de estado sólido, en
los que se almacenan los archivos y desde los que se recuperan según las peticiones del
cliente.

Un DFS es un sistema de archivos cuyos clientes, servidores y dispositivos de
almacenamiento están dispersos entre las máquinas de un sistema distribuido. En
consecuencia, la actividad de servicio debe realizarse a través de la red. En lugar de un
único repositorio de datos centralizado, el sistema suele disponer de múltiples
dispositivos de almacenamiento independientes. Como vemos, la configuración e
implementación concreta de un DFS puede variar de un sistema a otro. En algunas
configuraciones, los servidores se ejecutan en máquinas dedicadas. En otras, una máquina
puede ser a la vez servidor y cliente.
Las características distintivas de un DFS son la multiplicidad y autonomía de los clientes y

servidores del sistema. Sin embargo, lo ideal es que un DFS parezca a sus clientes un
sistema de archivos convencional y centralizado. Es decir, la interfaz cliente de un DFS no
debería distinguir entre archivos locales y remotos. Corresponde al DFS localizar los
archivos y organizar el transporte de los datos. Un DFS transparente, al igual que los
sistemas distribuidos transparentes mencionados anteriormente, facilita la movilidad del
usuario llevando su entorno, por ejemplo, el directorio personal del usuario, a cualquier
lugar en el que se conecte.
La medida más importante para evaluar el rendimiento de un DFS es el tiempo necesario

para satisfacer las peticiones de servicio. En los sistemas convencionales, este tiempo se
compone del tiempo de acceso al almacenamiento y una pequeña cantidad de tiempo de
procesamiento de la CPU. En un DFS, sin embargo, un acceso remoto tiene la sobrecarga
adicional asociada a la estructura distribuida. Esta sobrecarga incluye el tiempo de entrega
de la solicitud a un servidor, así como el tiempo para obtener la respuesta a través de la
red de vuelta al cliente. Para cada dirección, además de la transferencia de la información,
existe la sobrecarga de la CPU al ejecutar el software del protocolo de comunicación. El
rendimiento de un DFS puede verse como otra dimensión de la transparencia del DFS. Es
decir, el rendimiento de un DFS ideal sería comparable al de un sistema de archivos
convencional.
La arquitectura básica de un DFS depende de sus objetivos finales. Los dos modelos
arquitectónicos más utilizados son el modelo cliente-servidor y el modelo basado en
clúster. El objetivo principal de una arquitectura cliente-servidor es permitir el
intercambio transparente de archivos entre uno o más clientes como si los archivos
estuvieran almacenados localmente en los equipos cliente individuales. Los sistemas de
archivos distribuidos NFS y Open AFS son ejemplos de ello. NFS es el DFS más común

basado en UNIX. Tiene varias versiones, pero en esta ocasión nos referimos a NFS Versión
3.
Si es necesario ejecutar muchas aplicaciones en paralelo sobre grandes conjuntos de datos

con alta disponibilidad y escalabilidad, el modelo basado en clúster es más apropiado que
el modelo cliente-servidor. Dos ejemplos bien conocidos son el sistema de archivos de
Google y el HDFS de código abierto, que se ejecuta como parte del marco Hadoop.
El modelo DFS cliente-servidor
En un modelo DFS cliente-servidor simple, el servidor almacena tanto los archivos como
los metadatos en un almacenamiento adjunto. En algunos sistemas, se puede utilizar más
de un servidor para almacenar distintos archivos. Los clientes se conectan al servidor a
través de una red y pueden solicitar acceso a los archivos del DFS poniéndose en contacto
con el servidor a través de un protocolo bien conocido como NFS Versión 3. El servidor se
encarga de realizar la autenticación, comprobar los permisos del archivo solicitado y, si
está justificado, entregar el archivo al cliente solicitante. Cuando un cliente realiza
cambios en el archivo, debe enviarlos al servidor, que posee la copia maestra del archivo.
Las versiones del archivo del cliente y del servidor deben mantenerse coherentes de
forma que se minimice el tráfico de red y la carga de trabajo del servidor en la medida de
lo posible.
El protocolo del sistema de archivos en red (NFS) fue desarrollado originalmente por Sun
Microsystems como un protocolo abierto, lo que favoreció su adopción temprana en
diferentes arquitecturas y sistemas. Desde el principio, el objetivo de NFS fue la
recuperación rápida y sencilla ante una falla del servidor. Para alcanzar este objetivo, el
servidor NFS se diseñó como un servidor sin estado; no realiza un seguimiento de qué
cliente está accediendo a qué archivo o de cosas como descriptores de archivo abiertos y
punteros de archivo. Esto significa que, cada vez que un cliente emite una operación de
archivo, por ejemplo, para leer un archivo, esa operación debe ser idempotente frente a
caídas del servidor. Idempotente describe una operación que puede realizarse más de una
vez y devolver el mismo resultado. En el caso de una operación de lectura, el cliente
mantiene un registro del estado, como el puntero del archivo, y puede simplemente
volver a emitir la operación si el servidor se ha caído y vuelve a estar en línea.
El sistema de archivos Andrew (AFS) fue creado en la Universidad Carnegie Mellon con un
enfoque en la escalabilidad. En concreto, los investigadores querían diseñar un protocolo

que permitiera al servidor dar soporte al mayor número posible de clientes. Esto
significaba minimizar las peticiones y el tráfico al servidor. Cuando un cliente solicita un
archivo, su contenido se descarga del servidor y se almacena en la memoria local del
cliente. Las actualizaciones del archivo se envían al servidor cuando se cierra el archivo, y
las nuevas versiones del archivo se envían al cliente cuando se abre el archivo. En
comparación, NFS es bastante parlanchín y enviará peticiones de lectura y escritura en
bloque al servidor cuando el archivo esté siendo utilizado por un cliente.
Tanto Open AFS como NFS están pensados para ser utilizados como complemento de los
sistemas de archivo locales. En otras palabras, usted no formatearía una partición de disco
duro con el sistema de archivos NFS. En su lugar, en el servidor, formatearía la partición
con un sistema de archivos local de su elección, como ext4, y exportaría los directorios
compartidos a través del DFS. En el cliente, basta con adjuntar los directorios exportados
al árbol del sistema de archivos. De este modo, el DFS puede desentenderse de la
responsabilidad del sistema de archivos local y concentrarse en las tareas distribuidas.
El modelo cliente-servidor DFS, por diseño, puede sufrir de un único punto de falla si el
servidor falla. La agrupación de computadores puede ayudar a resolver este problema
mediante el uso de componentes redundantes y métodos de agrupación tales que los
fallas se detectan y la conmutación por error a los componentes que funcionan continúa
las operaciones del servidor. Además, el servidor presenta un cuello de botella para todas
las peticiones tanto de datos como de metadatos, lo que provoca problemas de
escalabilidad y ancho de banda.
El modelo DFS basado en clústers
A medida que aumenta la cantidad de datos, la carga de trabajo de E/S y el

procesamiento, también lo hace la necesidad de que un DFS sea tolerante a fallas y
escalable. No se pueden tolerar grandes cuellos de botella y es de esperar que se
produzcan fallas en los componentes del sistema. La arquitectura basada en clústeres se
desarrolló en parte para satisfacer estas necesidades. La siguiente figura ilustra un
ejemplo de modelo DFS basado en clúster. Este es el modelo básico presentado por el
Google File System (GFS) y el Hadoop Distributed File System (HDFS). Uno o más clientes
están conectados a través de una red a un servidor maestro de metadatos y a varios
servidores de datos que albergan fragmentos, o porciones, de archivos. El servidor de
metadatos mantiene un mapa de los servidores de datos que contienen fragmentos de
archivos, así como un mapa jerárquico tradicional de directorios y archivos. Cada

fragmento de archivo se almacena en un servidor de datos y se replica un determinado
número de veces, por ejemplo, tres veces, para protegerlo contra fallas de componentes y
para un acceso más rápido a los datos, los servidores que contienen los fragmentos
replicados tienen acceso rápido a esos fragmentos.
Para acceder a un archivo, el cliente debe ponerse en contacto con el servidor de

metadatos. A continuación, el servidor de metadatos devuelve al cliente las identidades
de los servidores de datos que contienen los fragmentos de archivo solicitados. El cliente
puede entonces ponerse en contacto con el servidor, o servidores, de datos más cercano
para recibir la información del archivo. Los distintos fragmentos del archivo pueden leerse
o escribirse en paralelo si están almacenados en diferentes servidores de datos, y puede
que sólo sea necesario contactar con el servidor de metadatos una vez en todo el proceso.
Esto hace que sea menos probable que el servidor de metadatos sea un cuello de botella
en el rendimiento. El servidor de metadatos también es responsable de redistribuir y
equilibrar los fragmentos de archivos entre los servidores de datos.
GFS se lanzó en 2003 para dar soporte a grandes aplicaciones distribuidas de uso intensivo
de datos. En el diseño de GFS influyeron cuatro observaciones principales:
1. Las fallas de los componentes de hardware son la norma más que la excepción y
deben esperarse rutinariamente.
2. Los archivos almacenados en un sistema de este tipo son muy grandes.

3. La mayoría de los archivos se modifican añadiendo nuevos datos al final del
archivo en lugar de sobrescribir los datos existentes.
4. Rediseñar las aplicaciones y la Interfaz de programación de aplicaciones (API:
Application Programming Interface) del sistema de archivos aumenta la flexibilidad
del sistema.
En consonancia con la cuarta observación, GFS exporta su propia API y exige que las
aplicaciones se programen con ella.
Poco después de desarrollar GFS, Google desarrolló una capa de software modularizada
llamada MapReduce para que se asentara sobre GFS. MapReduce permite a los
desarrolladores realizar cálculos paralelos a gran escala con mayor facilidad y aprovecha
las ventajas del sistema de archivos de la capa inferior. Más tarde, HDFS y el marco
Hadoop, que incluye módulos apilables como MapReduce sobre HDFS, se crearon a partir
del trabajo de Google. Al igual que GFS y MapReduce, Hadoop permite procesar grandes
conjuntos de datos en entornos informáticos distribuidos. Como se ha sugerido antes, el
impulso para crear un marco de este tipo se produjo porque los sistemas tradicionales no
podían escalar a la capacidad y el rendimiento que necesitaban los proyectos de big data,
al menos no a precios razonables. Algunos ejemplos de proyectos de big data son el
rastreo y análisis de redes sociales, datos de clientes y grandes cantidades de datos
científicos para detectar tendencias.
Nombrado y transparencia del DFS
El nombrado es una correspondencia entre objetos lógicos y físicos. Por ejemplo, los
usuarios tratan con objetos de datos lógicos representados por nombres de archivos,
mientras que el sistema manipula bloques físicos de datos almacenados en pistas de
disco. Normalmente, un usuario se refiere a un archivo mediante un nombre de texto.
Este último se asigna a un identificador numérico de nivel inferior que, a su vez, se asigna
a bloques de disco. Esta asignación multinivel proporciona a los usuarios una abstracción
de un archivo que oculta los detalles de cómo y dónde se almacena el archivo en el disco.
En un DFS transparente, se añade una nueva dimensión a la abstracción: la de ocultar en

qué parte de la red se encuentra el archivo. En un sistema de archivos convencional, el
rango de la asignación de nombres es una dirección dentro de un disco. En un DFS, este
rango se amplía para incluir la máquina específica en cuyo disco se almacena el archivo. Ir
un paso más allá con el concepto de tratar los archivos como abstracciones lleva a la

posibilidad de replicación de archivos. Dado un nombre de archivo, el mapeo devuelve un
conjunto de las ubicaciones de las réplicas de este archivo. En esta abstracción, tanto la
existencia de múltiples copias como sus ubicaciones están ocultas.
Estructuras de nombrado
Debemos diferenciar dos nociones relacionadas en lo que respecta a las correspondencias

de nombres en una DFS:
 Transparencia de ubicación. El nombre de un archivo no revela ninguna pista sobre

su ubicación física.
 Independencia de la ubicación. No es necesario cambiar el nombre de un archivo
cuando cambia su ubicación física de almacenamiento.
Ambas definiciones están relacionadas con el nivel de nombrado comentado

anteriormente, ya que los archivos tienen nombres diferentes a distintos niveles (es decir,
nombres textuales a nivel de usuario e identificadores numéricos a nivel de sistema). Un
esquema de nombrado independiente de la ubicación es una asignación dinámica, ya que
puede asignar el mismo nombre de archivo a diferentes ubicaciones en dos momentos
distintos. Por lo tanto, la independencia de ubicación es una propiedad más fuerte que la
transparencia de ubicación.
En la práctica, la mayoría de los DFS actuales proporcionan una asignación estática y

transparente para los nombres de usuario. Algunos soportan la migración de archivos, es
decir, cambiar la ubicación de un archivo automáticamente, proporcionando
independencia de ubicación. Por ejemplo, Open AFS admite la independencia de ubicación
y la movilidad de archivos. HDFS incluye la migración de archivos, pero lo hace sin seguir
los estándares POSIX, lo que proporciona más flexibilidad en la implementación y la
interfaz. HDFS realiza un seguimiento de la ubicación de los datos, pero oculta esta
información a los clientes. Esta transparencia de ubicación dinámica permite al
mecanismo subyacente autoajustarse. En otro ejemplo, el servicio de almacenamiento en
la nube S3 de Amazon proporciona bloques de almacenamiento bajo demanda a través de
API, colocando el almacenamiento donde lo considera oportuno y moviendo los datos
según sea necesario para cumplir los requisitos de rendimiento, fiabilidad y capacidad.
Algunos aspectos pueden diferenciar aún más la independencia de la ubicación y la
transparencia de la ubicación estática:
 La separación de los datos de la ubicación, tal y como muestra la independencia de

la ubicación, proporciona una mejor abstracción para los archivos. El nombre de un

archivo debe indicar sus atributos más significativos, que son su contenido y no su
ubicación. Los archivos independientes de la ubicación pueden verse como
contenedores lógicos de datos que no están vinculados a una ubicación de
almacenamiento específica. Si sólo se admite la transparencia de ubicación
estática, el nombre de archivo sigue denotando un conjunto específico, aunque
oculto, de bloques físicos de disco.
 La transparencia de ubicación estática proporciona a los usuarios una forma
cómoda de compartir datos. Los usuarios pueden compartir archivos remotos
simplemente nombrando los archivos de una manera transparente a la ubicación,
como si los archivos fueran locales. Dropbox y otras soluciones de almacenamiento
en la nube funcionan de este modo. La independencia de la ubicación promueve
compartir el espacio de almacenamiento en sí, así como los objetos de datos.
Cuando los archivos pueden movilizarse, el espacio de almacenamiento global de
todo el sistema parece un único recurso virtual. Una posible ventaja es la
capacidad de equilibrar la utilización del almacenamiento en todo el sistema.
 La independencia de la ubicación separa la jerarquía de nombrado de la jerarquía
de dispositivos de almacenamiento y de la estructura entre computadores. En
cambio, si se utiliza la transparencia de localización estática, aunque los nombres
sean transparentes, podemos exponer fácilmente la correspondencia entre las
unidades componentes y las máquinas. Las máquinas se configuran siguiendo un
patrón similar al de la estructura de nombrado. Esta configuración puede restringir
innecesariamente la arquitectura del sistema y entrar en conflicto con otras
consideraciones. Un servidor a cargo de un directorio raíz es un ejemplo de
estructura dictada por la jerarquía de nombrado y contradice las directrices de
descentralización.
Una vez completada la separación entre nombre y ubicación, los clientes pueden acceder
a los archivos que residen en sistemas de servidores remotos. De hecho, estos clientes
pueden no tener disco y depender de los servidores para proporcionar todos los archivos,
incluido el núcleo del sistema operativo. Sin embargo, se necesitan protocolos especiales
para la secuencia de arranque. Consideremos el problema de hacer llegar el kernel a una
estación de trabajo sin disco. La estación de trabajo sin disco no tiene kernel, por lo que
no puede utilizar el código DFS para recuperar el kernel. En su lugar, se invoca un
protocolo de arranque especial, almacenado en memoria de sólo lectura (ROM) en el
cliente. Habilita la conexión en red y recupera sólo un archivo especial, el kernel o código
de arranque, desde una ubicación fija. Una vez que el kernel se copia a través de la red y

se carga, su DFS pone a disposición todos los demás archivos del sistema operativo. Las
ventajas de los clientes sin disco son muchas, entre ellas un menor costo, ya que las
máquinas cliente no necesitan discos, y una mayor comodidad, ya que cuando se produce
una actualización del sistema operativo, sólo es necesario modificar el servidor. Las
desventajas son la complejidad añadida de los protocolos de arranque y la pérdida de
rendimiento derivada del uso de una red en lugar de un disco local.
Esquemas de nombrado
Existen tres enfoques principales para los esquemas de nombrado en un DFS. En el

enfoque más sencillo, un archivo se identifica mediante una combinación de su nombre
de host y su nombre local, lo que garantiza un nombre único para todo el sistema. En Ibis,
por ejemplo, un archivo se identifica unívocamente por el nombre host:local-name, donde
local-name es una ruta tipo UNIX. El sistema de URL de Internet también utiliza este
enfoque. Este esquema de nombrado no es transparente ni independiente de la
ubicación. El DFS está estructurado como una colección de unidades componentes
aisladas, cada una de las cuales es un sistema de archivos convencional completo. Las
unidades componentes permanecen aisladas, aunque se proporcionan medios para
referirse a archivos remotos.
El segundo enfoque fue popularizado por NFS. NFS proporciona un medio para adjuntar
directorios remotos a directorios locales, dando así la apariencia de un árbol de
directorios coherente. Las primeras versiones de NFS sólo permitían acceder de forma
transparente a los directorios remotos previamente montados. La aparición de la función
de montaje automático, o automontaje, permitió realizar montajes a petición basándose
en una tabla de puntos de montaje y nombres de estructuras de archivos. Los
componentes están integrados para soportar la compartición transparente, pero esta
integración es limitada y no es uniforme, porque cada máquina puede adjuntar diferentes
directorios remotos a su árbol. La estructura resultante es versátil.
Podemos lograr la integración total de los sistemas de archivos componentes utilizando un

tercer enfoque. En este caso, una única estructura de nombres global abarca todos los
archivos del sistema. Open AFS proporciona un único espacio de nombres global para los
archivos y directorios que exporta, lo que permite una experiencia de usuario similar en
diferentes máquinas cliente. Idealmente, la estructura compuesta del sistema de archivos
es la misma que la de un sistema de archivos convencional. En la práctica, sin embargo, los
numerosos archivos especiales, por ejemplo, los archivos de dispositivo UNIX y los

directorios binarios específicos de cada máquina, dificultan la consecución de este
objetivo.
Para evaluar las estructuras de nombrado, nos fijamos en su complejidad administrativa.

La estructura más compleja y difícil de mantener es la estructura NFS. Dado que cualquier
directorio remoto puede adjuntarse en cualquier lugar del árbol de directorios local, la
jerarquía resultante puede estar muy desestructurada. Si un servidor deja de estar
disponible, algún conjunto arbitrario de directorios en diferentes máquinas deja de
estarlo. Además, un mecanismo de acreditación independiente controla qué máquina
puede adjuntar qué directorio a su árbol. Así, un usuario puede acceder a un árbol de
directorios remoto en un cliente, pero no en otro.
Técnicas de implementación
La implementación de un sistema de nombrado transparente requiere la asignación de un

nombre de archivo a la ubicación asociada. Para que esta asignación sea manejable,
debemos agregar conjuntos de archivos en unidades componentes y proporcionar la
asignación en función de la unidad componente en lugar de en función de cada archivo.
Esta agregación también tiene fines administrativos. Los sistemas tipo UNIX utilizan el
árbol jerárquico de directorios para proporcionar la correspondencia entre nombres y
ubicaciones y para agregar archivos recursivamente en directorios.
Para mejorar la disponibilidad de la información de mapeo crucial, podemos utilizar la

replicación, el almacenamiento en caché local, o ambos. Como hemos señalado, la
independencia de la ubicación significa que la cartografía cambia con el tiempo. Por lo
tanto, replicar la cartografía hace imposible una actualización sencilla pero coherente de
esta información. Para superar este obstáculo, podemos introducir identificadores de
archivo de bajo nivel, independientes de la localización, Open AFS utiliza este enfoque. Los
nombres de archivo textuales se asignan a identificadores de archivo de nivel inferior que
indican a qué unidad componente pertenece el archivo. Estos identificadores siguen
siendo independientes de la ubicación. Pueden ser replicados y almacenados en caché
libremente sin ser invalidados por la migración de unidades componentes. El precio
inevitable es la necesidad de un segundo nivel de asignación, que asigna unidades
componentes a ubicaciones y necesita un mecanismo de actualización sencillo pero
coherente. La implementación de árboles de directorios tipo UNIX mediante estos
identificadores de bajo nivel e independientes de la ubicación hace que toda la jerarquía
sea invariable ante la migración de unidades componentes. El único aspecto que cambia
es la asignación de las ubicaciones de los componentes.

Una forma habitual de implementar identificadores de bajo nivel es utilizar nombres
estructurados. Estos nombres son cadenas de bits que suelen tener dos partes. La primera
parte identifica la unidad componente a la que pertenece el archivo; la segunda parte
identifica el archivo concreto dentro de la unidad. Son posibles variantes con más partes.
La invariante de los nombres estructurados, sin embargo, es que las partes individuales
del nombre son siempre únicas sólo dentro del contexto del resto de las partes. Siempre
podemos obtener la unicidad teniendo cuidado de no reutilizar un nombre que todavía
está en uso, añadiendo suficientes bits más, método que se utiliza en Open AFS, o
utilizando una marca de tiempo como una parte del nombre, como se hizo en
ApolloDomain. Otra forma de ver este proceso es que estamos tomando un sistema de
localización transparente, como Ibis, y añadiendo otro nivel de abstracción para producir
un esquema de nombrado independiente de la localización.
Acceso remoto a archivos
A continuación, consideremos un usuario que solicita acceso a un archivo remoto. El

servidor que almacena el archivo ha sido localizado por el esquema de nombrado, y ahora
debe tener lugar la transferencia real de datos. Una forma de realizar esta transferencia es
a través de un mecanismo de servicio remoto, mediante el cual las solicitudes de acceso
se envían al servidor, la máquina del servidor realiza los accesos y sus resultados se
reenvían al usuario. Una de las formas más comunes de implementar el servicio remoto es
el paradigma RPC. Existe una analogía directa entre los métodos de acceso al disco en los
sistemas de archivos convencionales y el método de servicio remoto en un DFS: utilizar el
método de servicio remoto es análogo a realizar un acceso al disco para cada solicitud de
acceso.
Para garantizar un rendimiento razonable de un mecanismo de servicio remoto, podemos

utilizar una forma de almacenamiento en caché. En los sistemas de archivos
convencionales, la razón de ser del almacenamiento en caché es reducir la E/S de disco,
aumentando así el rendimiento, mientras que, en los DFS, el objetivo es reducir tanto el
tráfico de red como la E/S de disco. A continuación, describimos la implementación del
almacenamiento en caché en un DFS y la comparamos con el paradigma básico de servicio
remoto.

Esquema básico de caché
El concepto de caché es sencillo. Si los datos necesarios para satisfacer la solicitud de

acceso no están ya almacenados en caché, se lleva una copia de los datos desde el
servidor al sistema cliente. Los accesos se realizan sobre la copia en caché. La idea es
retener en la caché los bloques de disco a los que se ha accedido recientemente, de modo
que los accesos repetidos a la misma información puedan gestionarse localmente, sin
tráfico de red adicional. Una política de sustitución, por ejemplo, el algoritmo LRU
mantiene acotado el tamaño de la caché. No existe una correspondencia directa entre los
accesos y el tráfico hacia el servidor. Los archivos se siguen identificando con una copia
maestra que reside en la máquina del servidor, pero las copias, o partes, del archivo están
dispersas en diferentes cachés. Cuando se modifica una copia en caché, los cambios
deben reflejarse en la copia maestra para preservar la semántica de coherencia
pertinente. El problema de mantener las copias en caché coherentes con el archivo
maestro es el problema de la coherencia de la caché. La memoria caché DFS podría
llamarse también memoria virtual de red. Actúa de forma similar a la memoria virtual
paginada bajo demanda, salvo que el almacén de respaldo suele ser un servidor remoto
en lugar de un disco local. NFS permite que el espacio de intercambio se monte de forma
remota, por lo que puede implementar la memoria virtual a través de una red, aunque
con la consiguiente penalización de rendimiento.
La granularidad de los datos almacenados en caché en un DFS puede variar desde bloques
de un archivo hasta un archivo completo. Normalmente, se almacenan en caché más
datos de los necesarios para satisfacer un único acceso, de modo que los datos
almacenados en caché puedan servir para muchos accesos. Este procedimiento es muy
parecido a la lectura anticipada en disco. Open AFS almacena archivos en grandes
fragmentos (64 KB). Los otros sistemas aquí analizados admiten el almacenamiento en
caché de bloques individuales en función de la demanda del cliente. Aumentar la unidad
de caché incrementa la tasa de aciertos, pero también aumenta la penalización por falla,
porque cada falla requiere que se transfieran más datos. También aumenta la posibilidad
de problemas de coherencia. La selección de la unidad de almacenamiento en caché
implica tener en cuenta parámetros como la unidad de transferencia de red y la unidad de
servicio del protocolo RPC si se utiliza un protocolo RPC. La unidad de transferencia de
red, para Ethernet, un paquete, es de aproximadamente 1,5 KB, por lo que las unidades
más grandes de datos en caché necesitan ser desmontadas para su entrega y
reensambladas en la recepción.

El tamaño del bloque y el tamaño total de la caché son obviamente importantes para los
esquemas de caché por bloques. En los sistemas tipo UNIX, los tamaños de bloque
habituales son 4 KB y 8 KB. Para cachés grandes, de más de 1 MB, son beneficiosos los
tamaños de bloque grandes, de más de 8 KB. Para cachés más pequeñas, los tamaños de
bloque grandes son menos beneficiosos porque dan lugar a menos bloques en la caché y a
una tasa de aciertos más bajo.
Ubicación de la caché
¿Dónde deben almacenarse los datos en caché, en disco o en memoria principal? Las
cachés de disco tienen una clara ventaja sobre las de memoria principal: son fiables. Las
modificaciones de los datos almacenados en caché se pierden en caso de falla si la caché
se guarda en memoria volátil. Además, si los datos almacenados en caché se guardan en
disco, siguen ahí durante la recuperación y no es necesario recuperarlos de nuevo. Sin
embargo, las cachés de memoria principal tienen sus propias ventajas:
 Las cachés de memoria principal permiten que las estaciones de trabajo no tengan
disco.
 Se puede acceder a los datos más rápidamente desde una caché en memoria
principal que desde una caché en disco.
 La tecnología avanza hacia memorias más grandes y menos costosas. Se prevé que
el aumento de rendimiento resultante supere las ventajas de las cachés de disco.
 Las cachés de servidor, utilizadas para acelerar la E/S de disco, estarán en la
memoria principal independientemente de dónde se encuentren las cachés de
usuario; si utilizamos cachés de memoria principal también en la máquina de
usuario, podemos construir un único mecanismo de caché para uso tanto de
servidores como de usuarios.
Muchas implementaciones de acceso remoto pueden considerarse híbridos de caché y

servicio remoto. En NFS, por ejemplo, la implementación se basa en el servicio remoto,
pero se aumenta con el almacenamiento en memoria caché del lado del cliente y del
servidor para mejorar el rendimiento. Por tanto, para evaluar los dos métodos, debemos
evaluar hasta qué punto se enfatiza uno u otro. El protocolo NFS y la mayoría de las
implementaciones no proporcionan caché de disco, pero Open AFS sí.

Política de actualización de la caché
La política utilizada para escribir bloques de datos modificados de vuelta a la copia

maestra del servidor tiene un efecto crítico en el rendimiento y la fiabilidad del sistema. La
política más sencilla consiste en escribir los datos en el disco en cuanto se colocan en
cualquier caché. La ventaja de una política write-through es la fiabilidad: se pierde poca
información cuando falla un sistema cliente. Sin embargo, esta política requiere que cada
acceso de escritura espere hasta que la información sea enviada al servidor, por lo que
provoca un bajo rendimiento de escritura. El almacenamiento en caché con write-through
equivale a utilizar el servicio remoto para los accesos de escritura y aprovechar el
almacenamiento en caché sólo para los accesos de lectura.
Una alternativa es la política de escritura diferida, también conocida como política write-
back, en la que retrasamos las actualizaciones de la copia maestra. Las modificaciones se
escriben en la caché y luego se escriben en el servidor. Esta política tiene dos ventajas
sobre la write-through. En primer lugar, como las escrituras se realizan en la caché, los
accesos de escritura se completan mucho más rápidamente. En segundo lugar, los datos
pueden sobrescribirse antes de volver a escribirse, en cuyo caso sólo es necesario escribir
la última actualización. Desafortunadamente, los esquemas write-back introducen
problemas de fiabilidad, ya que los datos no escritos se pierden cada vez que una máquina
de usuario se bloquea. Las variaciones de la política write-back difieren en el momento en
que los bloques de datos modificados se envían al servidor. Una alternativa es vaciar un
bloque cuando está a punto de ser expulsado de la caché del cliente. Esta opción puede
dar como resultado un buen rendimiento, pero algunos bloques pueden permanecer en la
caché del cliente durante mucho tiempo antes de ser escritos de nuevo en el servidor. Un
compromiso entre esta alternativa y la política write-through es escanear la caché a
intervalos regulares y vaciar los bloques que han sido modificados desde el escaneo más
reciente, igual que UNIX escanea su caché local. NFS utiliza esta política para los datos de
archivos, pero una vez que se emite una escritura al servidor durante un vaciado de caché,
la escritura debe llegar al disco del servidor antes de que se considere completa. NFS trata
los metadatos (datos de directorio y datos de atributos de archivo) de forma diferente.
Cualquier cambio en los metadatos se envía de forma sincrónica al servidor. De este
modo, se evita la pérdida de la estructura de archivos y la corrupción de la estructura de
directorios cuando un cliente o el servidor se bloquean.
Otra variación de la política write-back consiste en escribir los datos en el servidor cuando
se cierra el archivo. Recibe el nombre de política de escritura durante el cierre y es

utilizada en Open AFS. En el caso de archivos que están abiertos por periodos cortos o son
modificados raramente, esta política no reduce significativamente el tráfico de red.
Además, la política de escritura al cerrar requiere que el proceso de cierre se retrase
mientras se escribe el archivo, lo que reduce las ventajas de rendimiento de las políticas
write-back. Sin embargo, en el caso de archivos que permanecen abiertos durante largos
periodos y se modifican con frecuencia, las ventajas de rendimiento de esta política frente
a la política write-back con un volcado más frecuente son evidentes.
Coherencia
Una máquina cliente se enfrenta a veces al problema de decidir si una copia de datos
almacenada localmente en caché es coherente con la copia maestra, y, por tanto, puede
utilizarse. Si la máquina cliente determina que sus datos almacenados en caché están
obsoletos, debe almacenar en caché una copia actualizada de los datos antes de permitir
nuevos accesos. Existen dos enfoques para verificar la validez de los datos almacenados
en caché:
Inicio por parte del cliente
El cliente inicia una comprobación de validez en la que se pone en contacto con el servidor
y comprueba si los datos locales son coherentes con la copia maestra. La frecuencia de la
comprobación de validez es el quid de este enfoque y determina la semántica de
coherencia resultante. Puede variar desde una comprobación antes de cada acceso hasta
una comprobación sólo en el primer acceso a un archivo, al abrir el archivo, básicamente.
Cada acceso asociado a una comprobación de validez se retrasa, en comparación con un
acceso servido inmediatamente por la caché. Alternativamente, las comprobaciones
pueden iniciarse a intervalos de tiempo fijos. Dependiendo de su frecuencia, la
comprobación de validez puede cargar tanto la red como el servidor.
Inicio por parte del servidor
El servidor registra, para cada cliente, los archivos, o partes de archivos, que almacena en
caché. Cuando el servidor detecta una posible incoherencia, debe reaccionar. Una
incoherencia potencial se produce cuando dos clientes diferentes en modos conflictivos
almacenan en caché un archivo. Si se implementa la semántica UNIX, podemos resolver la
incoherencia potencial haciendo que el servidor desempeñe un papel activo. El servidor
debe ser notificado cada vez que se abra un archivo, y el modo previsto, lectura o
escritura, debe indicarse para cada apertura. El servidor puede actuar cuando detecta que

un archivo se ha abierto simultáneamente en modos contradictorios desactivando el
almacenamiento en caché de ese archivo. Al desactivar la caché, se pasa a un modo de
funcionamiento de servicio remoto.
En un DFS basado en clúster, la cuestión de la coherencia de la caché se complica por la

presencia de un servidor de metadatos y varios fragmentos de datos de archivo replicados
en varios servidores de datos. Utilizando nuestros ejemplos anteriores de HDFS y GFS,
podemos comparar algunas diferencias. HDFS sólo permite operaciones de escritura de
anexos, sin escrituras aleatorias y con un único escritor de archivos, mientras que GFS sí
permite escrituras aleatorias con escritores concurrentes. Esto complica enormemente las
garantías de consistencia de escritura para GFS, mientras que las simplifica para HDFS.
Modos de comunicación entre sistemas distribuidos según el tipo de hardware

Según el tipo de hardware es posible enumerar los siguientes modos de comunicación
entre los sistemas distribuidos:
Tipo de
Modo de comunicación
Hardware
Fuertemente
Al tener memoria común se comunican a través de un buffer común.
acoplado
Al no tener memoria compartida la comunicación se debe realizar a
través de RPC (Remote Procedure Control – Llamadas a procedimientos
remotos)
Débilmente
Cuando un proceso A quiere comunicarse con otro B, primero A debe
acoplado
construir el mensaje en su propio espacio de direcciones de memoria,
luego ejecuta una llamada al sistema para que el sistema operativo
busque el mensaje y lo envía a través de la red hacia B.
Para poder realizar esa comunicación mediante mensajes se necesita acordar una serie de
aspectos que ocupan una amplia gama de niveles (desde el más bajo de transmisión de los
bits hasta los de más alto nivel) donde se explicita cómo debe expresarse la información,
por ejemplo:
 Qué tensión hay que utilizar para enviar un bit 0 y cuál para enviar un bit 1.
 Cómo sabe el receptor cuál es el último bit del mensaje.
 Cómo detectar si un mensaje ha sido perdido o dañado.
 Cuál es la longitud de la cadena de datos y cómo se representan.

En una posible implementación del paso de mensajes los procesos hacen uso de los
servicios de un módulo de paso de mensajes pudiéndose escribir las peticiones de servicio
en términos de primitivas y parámetros. Aquí, una primitiva especificará la función que se
quiere hacer mientras que los parámetros son usados para transferir los datos y la
información de control.
La estructura de las primitivas variará según cuál sea el software de paso de mensajes
utilizado. Esta estructura puede implementarse como una llamada a un procedimiento o
como un mensaje propiamente dicho a un proceso que sea parte del sistema operativo.
Habitualmente la primitiva Send se utiliza cuando un proceso quiere enviar un mensaje,
siendo sus parámetros el identificador del proceso receptor y el contenido del mensaje, y
es el módulo de paso de mensajes el encargado de construir la unidad de datos que
incluirá a estos elementos y que será enviada a la computadora que aloja al proceso
receptor del mensaje utilizando algún tipo de servicios de comunicación, como el TCP/IP.
Al recibir el equipo receptor la unidad de datos, el servicio de comunicación pasa esta al
módulo de paso de mensajes que examinará el campo identificación de proceso y
almacenará al mensaje en el búfer de proceso receptor. Ante esta situación, el proceso
receptor debe explicitar su deseo de recibir un mensaje. Esto lo hace determinando un
área de buffer e informando al módulo de paso de mensajes mediante la primitiva
Receive. Otra opción sería que, al momento de recibir un mensaje el módulo de paso de
mensajes identifique cuál es el proceso destinatario mediante una señal Receive para
luego dejar disponible el mensaje recibido en un buffer compartido.
Otras características destacadas del paso de mensajes son:
 El servicio puede ser confiable o no confiable. El servicio confiable es aquel que, si

es posible, garantiza la entrega. Para poder cumplir con esto, el servicio realiza una
comprobación de errores, acuse de recibo, retransmisión y reordenamiento de
mensajes desordenados, de forma tal que no necesita informar al proceso emisor
de que el mensaje ha sido enviado sin problemas. Por su parte, el servicio de paso
de mensajes no confiable envía el mensaje por la red, pero no indica ni el éxito ni
el fracaso del envío. Ante este hecho, los procesos que necesiten una confirmación
de que el mensaje ha sido entregado correctamente, deberán enviar y recibir
mensajes para cumplir con esta necesidad.
 El servicio puede ser bloqueante (sincrónico) o no bloqueante (asincrónico). Las
primitivas no bloqueantes no suspenden a un proceso como resultado de realizar
un Send o Receive, de forma que, cuando un proceso realiza una primitiva Send, el

sistema operativo devuelve el control al proceso no bien el mensaje fue puesto en
la cola para transmitirlo o se lo ha copiado. Aunque estas primitivas proveen un
buen uso de los servicios de paso de mensajes por parte de los procesos, tienen
como desventaja la dificultad de chequear y depurar a los programas que utilicen
estas primitivas. En un servicio bloqueante, un Send no devolverá el control al
proceso emisor hasta que el mensaje ha sido transmitido, si el servicio no es
confiable, o hasta que el mensaje haya sido enviado y se haya recibido el acuse de
recibo, cuando el servicio es confiable. En el caso de un Receive bloqueante, éste
no devolverá el control hasta que el mensaje haya sido colocado en el búfer
correspondiente.
Llamada a un procedimiento remoto (RPC)

El modelo cliente servidor es una forma apropiada de implementar un sistema operativo
distribuido, pero el inconveniente es que los procedimientos de Send y Receive se basan
en operaciones de E/S que no son las más apropiadas. En 1984 BIRELL y NELSON
postularon una forma distinta de abordar el problema de implementar el sistema
distribuido que consiste en que, si un proceso en la máquina “A” desea llamar a un
procedimiento en la máquina “B”, el proceso que realiza la llamada a “A” se suspende y se
realiza la ejecución en “B”. La información se transporta de un lado a otro por parámetros
y regresa en el resultado del procedimiento. En este caso el programador no se preocupa
de la transferencia de mensajes o de las operaciones de E/. Esta técnica se la denomina
llamada a un procedimiento remoto o RPC. Por lo general el procedimiento que hace la
llamada se llama cliente y el procedimiento que llamó se lo llama servidor.
En este esquema, lo que se quiere hacer es que una llamada a un procedimiento remoto
sea lo más parecida posible a una llamada local. Luego, para llamar a un procedimiento
remoto, el cliente debe enlazarse con una rutina de biblioteca conocida como resguardo
del cliente, la cual representará al servidor en el espacio de direcciones del cliente.
Asimismo, el servidor se enlazará con un procedimiento conocido como resguardo del
servidor. Ambos procedimientos ocultarán el hecho de que la llamada al procedimiento
desde el cliente al servidor no es local.
Los pasos para llevar a cabo una RPC son los siguientes:

1. Ocurre cuando el cliente llama al resguardo del cliente. Esta llamada es una
llamada a un procedimiento local, donde los parámetros se meten en la pila de la
manera habitual.
2. Es cuando el resguardo del cliente empaqueta los parámetros, o marshaling, en un
mensaje y realiza una llamada al sistema para enviarlo.
3. Sucede cuando el kernel envía el mensaje de la máquina cliente a la máquina
servidor.
4. Cuando el kernel pasa el paquete entrante al resguardo del servidor (que por lo
general llama a receive desde antes).
5. Cuando el resguardo del servidor llama al procedimiento del servidor. La respuesta
sigue la misma ruta en dirección opuesta.
Lo importante en este desarrollo es que el procedimiento cliente sólo hace una llamada a
procedimiento local al resguardo del cliente, el cual tiene el mismo nombre que el
procedimiento del servidor. Puesto que el procedimiento del cliente y el resguardo del
cliente pertenecen al mismo espacio de direcciones, los parámetros se pasan por valor o
por referencia. Asimismo, un procedimiento llama al procedimiento del servidor en su
espacio de direcciones, con los parámetros que espera. Así se lleva a cabo la comunicación
remota al simular una llamada a un procedimiento local.
Sin embargo, este esquema presenta algunas dificultades, a saber:
 No es posible, o al menos puede resultar muy complicado, el uso de parámetros

tipo puntero porque el cliente y el servidor se encuentran en distintos espacios de
direcciones.
 Aunque el lenguaje permita el uso de parámetros tipo vector sin una longitud
definida, le resultará imposible al cliente poder empaquetar los parámetros
porque no tiene forma de determinar qué tan grandes son.
 No siempre se pueden deducir los tipos de los parámetros.
 El uso de las variables globales empleado tanto por los procedimientos que llaman
como por los que son llamados o empleadas como parámetros. Si quien llama se
traslada a una computadora remota, el código fallará porque las variables globales
ya no están compartidas.
GRIDS (Mallas)
Un GRID es un conjunto inmenso de computadoras con las siguientes características:

 Las computadoras que lo forman se encuentran geográficamente dispersas.
 Esas máquinas son bastante heterogéneas.
 Se conecta mediante una red privada o Internet.
 Ofrece un conjunto de servicios para sus usuarios.
 Es una colección de computadoras independientes.
 Las computadoras que lo forman están, generalmente, en dominios
administrativos distintos.
 Las computadoras ejecutan un nivel común de middleware para permitir que los
programas y usuarios accedan a todos los recursos de una manera conveniente y
consistente.
 Su principal objetivo es la compartición de los ciclos de la CPU como así también el
hardware especializado y las bases de datos.
Usualmente un GRID funciona de la siguiente forma:
Paso 1
Toda computadora integrante del GRID ejecuta un grupo de programas que gestionan la
computadora y la integran al GRID. Habitualmente este software se encarga de la
autenticación y el inicio de sesión de los usuarios remotos, de anunciar y descubrir
recursos, programar y ubicar trabajos, etcétera.
Paso 2
Siempre que un usuario realiza un trabajo, el software del GRID primero determina en
dónde se tienen recursos de hardware, software y de datos libres para la ejecución del
trabajo, luego envía el trabajo a ese lugar, prepara su ejecución y más tarde devuelve los
resultados obtenidos al usuario.
Como ejemplo de middleware para un GRID se tiene a Globus Toolkit utilizable en varias
plataformas y que puede soportar varios esquemas de GRID. Globus suministra un
entorno de trabajo que les permite a los usuarios compartir computadoras, archivos y
muchos otros recursos de forma flexible y con mucha seguridad sin tener que sacrificar la
autonomía local. Debido a estas cualidades es que se lo usa como plataforma en la
construcción de una gran cantidad aplicaciones distribuidas.

Ejemplos históricos de sistemas operativos distribuidos
Seguidamente veremos algunos detalles de distintos sistemas operativos distribuidos.
AMOEBA
Este sistema operativo se originó en Ámsterdam, Holanda en 1981, como proyecto de

investigación en cómputo distribuido y paralelo. Fue diseñado por Andrew S. Tanenbaum
y tres de sus estudiantes de doctorado, Frans Kaashoek, Sape J. Mullender y Robbert van
Renesse.
El objetivo principal del proyecto AMOEBA era construir un sistema operativo distribuido y
transparente. Un usuario común podría no percibir la diferencia entre AMOEBA y un
sistema tradicional de tiempo compartido como UNIX, pero la diferencia real es que el que
trabaja en AMOEBA entra, edita, mueve programas y archivos entre varias máquinas
dispersas en la red y entre estas máquinas están los servidores de procesos, de archivos,
de directorios, de cómputos, pero el usuario no es consciente de ello; porque todo parece
como un sistema ordinario de tiempo compartido.
Una característica de AMOEBA es que cuando el usuario entra al sistema lo hace como un
todo y no como una máquina específica, es decir que todos los recursos pertenecen al
sistema como un todo y son controlados por él.
MACH
Mach nace de un sistema anterior llamado RIG (Rochester Intelligent Gateway) que se
inició en la Universidad de Rochester en 1975. Fue escrito para una minicomputadora de
16 bits de Data General.
En 1986 después de varias evoluciones de RIG con un nuevo proyecto aparece MACH en
su primera versión, para implementarlo en una VAX 11/784 que era un multiprocesador
de 4 CPU, posteriormente se realizaron versiones para IBM PC/RT y para SUN 3. A pesar
de tener posibilidad de su uso en redes, en esa época se concebía más como un sistema
para un multiprocesador que para una red.
Los objetivos principales de MACH eran:
 Proporcionar una base para la construcción de otros sistemas operativos.

 Permitir acceso transparente a los recursos de red.

 Explotar el paralelismo tanto en el sistema como en las aplicaciones.
 Hacer que MACH se pueda transportar a una colección más grande de máquinas.
CHORUS
Nace en un instituto de investigación de Francia, INRIA, en 1980 como proyecto de

investigación en sistemas distribuidos. Desde sus orígenes han aparecido 4 versiones
numeradas como 0, 1 ,2 y 3. La idea inicial era modelar aplicaciones distribuidas como
colección de procesos estructurados, cada uno de los cuales alternaban entre la
realización de una operación atómica y la ejecución de un paso de comunicación. Cada
máquina del sistema ejecutaba el mismo núcleo que controlaba a los procesos, la
comunicación, los archivos y los dispositivos de E/S. Su primera versión fue desarrollada
en Pascal interpretado y se ejecutó, en una colección de procesadores 8086 conectados
mediante una red anillo, a partir de 1982.
La versión 1 (1982-1984) fue escrita para el multiprocesador SM90 que constaba de 8

procesadores 68020 de MOTOROLA en bus común, donde un procesador utilizaba UNIX y
los otros siete ejecutaban CHORUS, utilizando el de UNIX para atender los servicios del
sistema y las E/S. También atendía varias SM90 conectadas mediante ETHERNET. Esta
versión también fue escrita en PASCAL, pero, en este caso, compilado y no interpretado.
La versión 2 (1984-1986) fue una rediseñada y escritura del sistema el lenguaje C y se

diseñó de manera tal que las llamadas fuesen compatibles con UNIX en el nivel de código
fuente y esto significaba que se podía recompilar los programas existentes en LINUX en
CHORUS. En esta versión se agregó un soporte para las aplicaciones distribuidas
incluyendo la ejecución remota y los protocolos para la asignación de nombres y la
localización distribuida.
La versión 3 se inició en 1987 y marcó la transición de un sistema de investigación a uno

de aplicación comercial, pues los desarrolladores salieron de la Universidad y formaron
una empresa, CHORUS SYSTEMS, para continuar con los desarrollos y su comercialización.
Desapareció en esta versión el concepto de procesos estructurados alternando con
transacciones atómicas y se introdujo el concepto de llamada a procedimientos remotos
(RPC) como el modelo comunicacional del sistema.
Para que esta versión pudiera ser una versión comercial se debió aumentar la capacidad
de emulación de UNIX y se agregó la compatibilidad binaria con el mismo, de manera tal
que se pudiesen correr programas en UNIX sin necesidad de recompilarlos.

Los objetivos del proyecto CHORUS fueron evolucionando con el tiempo de la misma
manera que fue evolucionando su arquitectura. Los objetivos que en la actualidad
mantienen vigencia son:
 Emulación de UNIX de alto rendimiento.

 Uso en sistemas distribuidos.
 Aplicaciones de tiempo real.
 Integración de la programación orientada a objetos en CHORUS.
Bibliografía de referencia del texto e imágenes
 Carretero Pérez, J.; De Miguel Anasagasti, P.; García Carballeira, F.; Pérez Costoya,
F. (2007). Sistemas Operativos: Una visión aplicada (2a ed.). Buenos Aires: Mc.
Graw Hill.
 Carretero Pérez, J., García Carballeira, F., & Pérez Costoya, F. (2021). Sistemas
Operativos: Una Visión Aplicada, Tercera Edición, Volumen I. Independently
Published.
 Carretero Pérez, J., García Carballeira, F., & Pérez Costoya, F. (2021). Sistemas
Operativos: Una Visión Aplicada, Tercera Edición, Volumen II. Independently
Published.
 Silberschatz, A.; Galvin, P. B.; Gagne, G. (2018). Operating System Concepts, Tenth
Edition. Hoboken, New Jersey: John Wiley & Sons, Inc.
 Silva, M. (2015). Sistemas Operativos. Ciudad Autónoma de Buenos Aires:
Alfaomega Grupo Editor.
 Stallings, W. (2018). Operating Systems: Internals and Design Principles, 9th
Edition; Editorial: Pearson.
 Stallings, W. (2012). Operating Systems, Internals and Design Principles, Seventh
Edition. Upper Saddle River; New Jersey: Pearson Education, Inc.
 Tanenbaum, A. S.; Bos, H. (2015). Modern Operating Systems, Fourth Edition.
 Tanenbaum, A. S.; Maarten Van Steen. (2009). Sistemas operativos modernos (3ª
ed.). México: Pearson/Prentice Hall.
 Wolf, Gunnar. (2015). Fundamentos de sistemas operativos. México. Instituto de
Investigaciones Económicas UNAM.

Apunte - Introducci N A Los Sistemas Distribuidos Ok

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Apunte - Introducci N A Los Sistemas Distribuidos Ok

Cargado por

Copyright:

Formatos disponibles

Introducción a los sistemas distribuidos

Las aplicaciones de los sistemas distribuidos van desde proporcionar un acceso

Podemos definir a un sistema distribuido de la siguiente forma:

Un sistema distribuido es aquel que administra los recursos de una colección de

© Universidad de Palermo. Prohibida la reproducción total o parcial de imágenes y textos. 1

Aceleración de los cálculos

© Universidad de Palermo. Prohibida la reproducción total o parcial de imágenes y textos. 2

La ventaja de un sistema distribuido es que estas funciones pueden realizarse a grandes

© Universidad de Palermo. Prohibida la reproducción total o parcial de imágenes y textos. 3

Resumiendo, como ventajas y desventajas tendríamos el siguiente cuadro:

Los microprocesadores proporcionan mejor relación precio / rendimiento que cualquier

Un sistema distribuido puede tener mayor poder de cómputo que un mainframe.

Al estar distribuido el procesamiento en muchas máquinas, la caída de una de ellas sólo

Crecimiento por incrementos

Se puede añadir poder de cómputos en pequeños incrementos

Un acceso sencillo también se aplica a datos secretos

© Universidad de Palermo. Prohibida la reproducción total o parcial de imágenes y textos. 4

Aún existe poco software para los sistemas distribuidos.

La red se puede saturar o causar otros problemas.

Características básicas de un sistema distribuido

Por su parte, como características básicas de un sistema distribuido podemos mencionar a

Inexistencia de reloj global

Ejemplos de sistemas distribuidos

Como ejemplos de sistemas distribuidos podemos mencionar a:

© Universidad de Palermo. Prohibida la reproducción total o parcial de imágenes y textos. 5

Términos vinculados con los sistemas operativos distribuidos

Es el encargado de gestionar en un sistema de computadoras una colección de recursos

Es el programa en ejecución (proceso) en un computador en red que acepta peticiones de

Son los programas en ejecución (procesos) solicitantes de servicios al servidor. Cuando un

Breve repaso de una clasificación del hardware

Un flujo de instrucciones es el conjunto de instrucciones secuenciales que son

Un programa que calcula el promedio de una lista de temperaturas tiene un flujo de

© Universidad de Palermo. Prohibida la reproducción total o parcial de imágenes y textos. 6

Un programa que calcula el promedio de una lista de temperaturas tiene un flujo de

© Universidad de Palermo. Prohibida la reproducción total o parcial de imágenes y textos. 7

La categoría MISD (Multiple Instruction Stream, Single Data Stream), corresponde a un

© Universidad de Palermo. Prohibida la reproducción total o parcial de imágenes y textos. 8

© Universidad de Palermo. Prohibida la reproducción total o parcial de imágenes y textos. 9

Clasificación del software. Tipos de sistemas distribuidos

© Universidad de Palermo. Prohibida la reproducción total o parcial de imágenes y textos. 10

Por ejemplo, un grupo de computadoras donde cada una tiene su procesador, su

Si se observa que se han desarrollado cuatro tipos de sistemas distribuidos según el

Sistema Operativo de Sistema Operativo Sistema Operativo de

¿Cómo se logra la comunicación? Archivos compartidos Mensajes Memoria compartida

¿Se requiere un acuerdo entre

¿Existe una cola de ejecución? No No Sí

¿Existe una semántica bien

© Universidad de Palermo. Prohibida la reproducción total o parcial de imágenes y textos. 11

Sistemas operativos de red

Un sistema operativo de red proporciona un entorno en el que los usuarios pueden

Inicio de sesión remoto

Una función importante de un sistema operativo de red es permitir a los usuarios

Transferencia remota de archivos

Otra función importante de un sistema operativo de red es proporcionar un mecanismo

© Universidad de Palermo. Prohibida la reproducción total o parcial de imágenes y textos. 12

Las aplicaciones básicas de almacenamiento en la nube permiten a los usuarios transferir

Sistemas operativos distribuidos

© Universidad de Palermo. Prohibida la reproducción total o parcial de imágenes y textos. 13

En algunas circunstancias, es posible que queramos transferir el cálculo, en lugar de los

Un cálculo de este tipo puede realizarse de diferentes maneras. Supongamos que el

Alternativamente, el proceso P puede enviar un mensaje al sitio A. El sistema operativo

© Universidad de Palermo. Prohibida la reproducción total o parcial de imágenes y textos. 14

Una extensión lógica de la migración informática es la migración de procesos. Cuando un