SISTEMAS DISTRIBUIDOS

TEMA 3: SERVICIOS DE ARCHIVOS DISTRIBUIDOS

DAVID RODRGUEZ HERNNDEZ

FECHA DE REVISIN: 16 Diciembre 2008
ZAMORA (CURSO 2008/2009)
david.rgh@gmail.com

Nota importante:
Este documento no pretende reemplazar al material propuesto por la UNED para la asignatura Sistemas
Distribuidos.
Su finalidad es presentar de una forma esquematizada los contenidos de la asignatura, para facilitar el
estudio de la misma. Es conveniente disponer de la bibliografa propuesta por la Universidad para su
estudio completo.
Cualquier sugerencia, comentario o correccin sobre este documento, envelo a david.rgh@gmail.com
para poder realizar los cambios necesarios.

INTRODUCCIN
Recordemos que uno de los principales objetivos de los sistemas distribuidos es el de compartir archivos. Aunque
esto se consigue en cierta medida en Internet, los requisitos actuales hacen que sea necesario un almacenamiento
persistente de datos y programas y su consiguiente distribucin.
Se conoce como sistema distribuido bsico a aquel sistema que trata de emular el funcionamiento de sistemas no
distribuidos para clientes ejecutndose en mltiples mquinas. Estos sistemas no tienen mltiples rplicas
persistentes de archivos ni soportan el ancho de banda y las garantas de temporizacin que necesitan los flujos
multimedia.
En principio, los sistemas de archivos fueron desarrollados para sistemas centralizados de computadores.
Posteriormente adquirieron caractersticas como el control de acceso o mecanismos de bloqueo a archivos. Estos
sistemas permiten que los programas almacenen y accedan a los archivos remotos de la misma forma que con los
locales. As, se reduce la necesidad de almacenamiento en disco local y permite economizar la gestin y el archivo
de datos persistentes. Adems, se puede usar para facilitar la implementacin de otros servicios (ej: servicio de
autenticacin de usuarios).
Al aparecer la programacin orientada a objetos distribuida, apareci tambin la necesidad del almacenamiento
persistente y la distribucin para los objetos compartidos (por ejemplo, serializando los objetos, aunque esto se
vuelve impracticable; hay otras aproximaciones como RMI o CORBA (aunque no aseguran la persistencia de los
objetos ni la replicacin de los objetos distribuidos)).
Actualmente se tiende a los sistemas de memoria compartida distribuida (DSM) y a los almacenes de objetos
persistentes.
En la figura 8.1 (pgina 293) se muestran los distintos tipos de sistemas de almacenamiento y sus propiedades (la
explicacin de las mismas se encuentra en esa misma pgina).
CARACTERSTICAS DE LOS SISTEMAS DE ARCHIVOS
Los sistemas de archivos son responsables de la organizacin, almacenamiento, recuperacin, nominacin,
comparticin y proteccin de los archivos. Los archivos se almacenan en medios no voltiles.
Contienen datos (secuencia de elementos de datos accesibles (cualquier porcin) con operaciones de lectura y
escritura) y atributos (informacin sobre el archivo: longitud, tipo, propietario).
En la Figura 8.3 (pgina 295) se muestra una estructura tpica del registro de atributos.
Se conoce como directorio a un archivo que relaciona los nombres con los identificadores internos de los archivos.
Estos directorios pueden incluir a otros directorios.
Se conoce como metadato a la informacin extra para la gestin de un sistema de archivos.
La Figura 8.2 (pgina 295) muestra los mdulos de un sistema de archivos; siendo que cada nivel slo depende de
los que estn debajo de l.
Sobre los archivos se aplican operaciones (en la pgina 296 se muestran las principales de un sistema UNIX, las
cules son llamadas al sistema, que suelen emplearse a travs de bibliotecas de funciones). En UNIX se registra una
lista de los archivos abiertos actualmente con un apuntador de lectura-escritura para cada uno (permite mantener
su posicin para las operaciones).
El sistema de archivos es responsable de aplicar el control de acceso; es decir, comprobar los permisos de un
usuario con una lista de control de acceso cada vez que se abre un archivo en un modo determinando.
REQUISITOS DEL SISTEMA DE ARCHIVOS DISTRIBUIDOS
Veamos los requisitos que deben cumplirse:

Transparencia: Tenemos los siguientes tipos de transparencias:

o

De acceso: Se debe acceder de la misma forma a archivos locales y remotos.

De ubicacin: Los archivos deben poder reubicarse sin necesidad de modificar el espacio de
nombres de archivo, que debe ser uniforme.

De movilidad:
cliente.

De prestaciones:
mantenerse.

De escala: El sistema debe poder ampliarse.

Los archivos deben poder moverse sin necesidad de modificar los programas

Aunque la carga vare dentro de cierto rango, las prestaciones deben

Actualizaciones concurrentes de archivos: Dos o ms clientes pueden actualizar simultneamente un

archivo concreto. Se deben controlar estas situaciones de concurrencia, aunque suelen ser tcnicas
costosas.

Replicacin de archivos: La replicacin permite equilibrar la carga entre distintos servidores y permite
tener otro archivo al que acceder si uno falla. Una forma limitada de replicacin es la cach local.

Heterogeneidad del hardware y del SO:

computadores y SSOO.

Tolerancia a fallos: El sistema debe funcionar aunque se presenten fallos del cliente o servidor. Ya vimos
en el tema anterior algunas semnticas para esto (mximo una vez, al menos una vez). Si un servidor es
sin estado, puede restablecerse el servicio tras un fallo sin necesidad de recuperar el estado previo.

Consistencia: Los sistemas de archivos convencionales y los proporcionados en UNIX usan una semntica
de actualizacin de una copia; es decir, los procesos ven el contenido es aquel que veran si slo hubiese
una copia. La actualizacin de las restantes copias suele implicar un cierto retardo.

Seguridad: En un SD, hay que autenticar las peticiones del cliente. El control de acceso se basa en
identificar al cliente y proteger el contenido de los mensajes de solicitud y respuesta con firmas digitales
y/o con encriptacin.

Eficiencia:
Deben ser igual (o ms) eficientes que los sistemas de archivos convencionales en
prestaciones y fiabilidad. Se debe poder administrar (instalar aplicaciones, configurar) de forma
adecuada.

El cliente y el servidor pueden componerse de distintos

CASOS DE ESTUDIO
Veamos algunos ejemplos:

Arquitectura del servicio de archivos: Es la base tanto de NFS como de AFS (ver ms adelante). Se
distinguen los siguientes mdulos: un cliente, que emula la interfaz de un sistema de archivos
convencional para los programas y un servidor, que realiza operaciones para los clientes en directorios y
archivos. Se puede realizar una implementacin sin estado del servidor.

NFS de SUN: Primer servicio de archivos diseado como un producto. Las definiciones de las interfaces
fundamentales son de dominio pblico. Proporciona acceso transparente a archivos remotos a clientes
ejecutndose sobre UNIX y otros sistemas. Cada computador tiene un cliente NFS y mdulos servidor
instalados en el ncleo del sistema. Cualquier mquina puede ser tanto cliente como servidor (relacin
simtrica). Su diseo es independiente del SO.

Andrew File System (AFS): Su intencin es soportar la comparticin de informacin a gran escala
minimizando la comunicacin cliente-servidor. Se logr copiando en la cach los archivos solicitados al

servidor hasta que ste tuviese una versin actualizada. Inicialmente se implement sobre una red de
estaciones de trabajo y servidores en BSD UNIX y el SO Mach. Ms tarde fue de dominio pblico. Despus,
se lanz una versin para Linux.

ARQUITECTURA DEL SERVICIO DE ARCHIVOS

Se estructura en tres componentes: un servicio de archivos plano, un servicio de directorio y un mdulo cliente.

Servicio de archivos plano: Se relaciona con la implementacin de operaciones en el contenido de los

archivos. Se usan UFID (identificadores nicos de archivos) para referirse a ellos en las solicitudes de
operaciones. Si recibe una solicitud para crear un archivo nuevo, genera un nuevo UFID y lo devuelve al
solicitante.

Servicio de directorio:
Permite transformar entre nombres de texto de los archivos y sus UFID
correspondientes. Mediante el nombre se puede obtener el UFID. Tiene operaciones para generar
directorios, para aadir nuevos nombres de archivo a los directorios y para obtener UFID desde los
directorios. Hace las veces de cliente del servicio de archivos plano.

Mdulo cliente: Integra y extiende las operaciones del servicio de archivos plano y el servicio de
directorio bajo una interfaz de programacin de aplicaciones sencilla. Puede implementar una cach de
los bloques de archivos que ha usado recientemente.

Interfaz del servicio de archivos plano: En la figura 8.6 (pgina 301) se puede observar una definicin de
la interfaz para un servicio de archivos planos (la interfaz RPC). Si IdArchivo contiene un UFID invlido o el
usuario no tiene permisos suficientes, se lanzan excepciones (un caso aparte es la operacin Crea,
evidentemente). Las operaciones ms importantes son las de lectura y escritura. Tenemos otras, como
DameAtributos y PonAtributos, con las que se puede acceder al registro de los atributos (PonAtributos
suele estar restringida al servicio de directorio que accede al archivo).
Es sencillo construir un mdulo cliente que emule las llamadas al sistema UNIX en trminos de las
operaciones de nuestro servicio de archivos planos y el servicio de directorio. El servicio de archivos
planos no tiene (al contrario que UNIX) operaciones open y close, sino que se accede a los archivos
directamente. Podemos encontrar dos diferencias importantes entre ambas interfaces:

Operaciones repetibles: En la interfaz del servicio de archivos planos, las operaciones son
idempotentes (si se ejecutan repetidas veces, el resultado es el mismo), excepto Crear, que
cada vez crear un fichero nuevo. En UNIX, las operaciones de lectura y escritura mueven un
puntero, por lo que cada operacin no generar el mismo resultado que la anterior.

Servidores sin estado: Pueden ser rearrancados tras un fallo y reanudar la operacin sin que
cliente y servidor tengan que restablecer su estado.

Control de acceso: En UNIX, los permisos se comprueban al solicitar la apertura de un archivo en cierto
modo. El UID del usuario utilizado en la comprobacin de derechos es el resultado del login autenticado
anterior del usuario y no puede ser alterado en las implementaciones no distribuidas. Los derechos se
mantienen hasta que se cierra el archivo. En las implementaciones distribuidas, la comprobacin se realiza
en el servidor y la identidad se pasa con cada solicitud. No se mantienen los derechos, porque entonces el
servidor no sera sin estado.
Puede realizarse entonces de dos formas: se puede realizar una comprobacin de acceso cuando se
convierte u nombre de archivo en un UFID, codificando los resultados en forma de habilitacin, que se
devuelve al cliente (se reenva en futuras solicitudes). Tambin se puede enviar la identidad del usuario
con cada solicitud del cliente y comprobar cada vez (este es ms comn).

Interfaz del servicio de directorio: Puede verse una definicin de interfaz RPC para un servicio de
directorio en la Figura 8.7 (pgina 303). Este servicio permite trasladar nombres a UFID, manteniendo las
equivalencias para tal fin. Cada operacin necesita el UFID del archivo objetivo, el cual se busca en este
servicio.

Tenemos dos operaciones posibles para modificar: AadeNombre (aade una entrada al directorio e
incrementa el contador de referencias en el registro de atributos de archivo) y DesNombra (elimina una
entrada de un directorio y decrementa el contador. Si ste llega a 0, se elimina el archivo).
Adems, DameNombres permite a los clientes examinar el contenido de los directorios, seleccionando
nombres mediante comparacin de patrones frente a una expresin regular proporcionada por el cliente.

Sistema de archivos jerrquico: UNIX es un ejemplo que proporciona este sistema. Los archivos forman
un rbol de jerarquas. Cada archivo puede ser referenciado mediante un path. En UNIX no es un sistema
estricto, ya que un archivo puede tener varios nombres o estar en varios directorios (mediante link).
Este tipo de sistema se puede implementar desde el mdulo cliente usando los servicios de directorio y de
archivos planos. Se construye un rbol de directorios con los archivos en las hojas. Su raz es un directorio
con una UFID bien conocida. Los atributos asociados con los archivos han de incluir un tipo que distingue
a los archivos de los directorios.

Agrupacin de archivos: Se conoce como grupo de archivos a una coleccin de archivos ubicados en un
servidor dado. Los grupos pueden reubicarse, pero un archivo no puede cambiar de grupo. Permiten la
asignacin de archivos a servidores de archivos almacenados en varios servidores. La representacin de
UFID de los sistemas que permiten esto tienen otro identificador para el grupo (debe ser nico (se
generan con un algoritmo que asegure la unicidad global)).

SISTEMA DE ARCHIVOS EN RED DE SUN (NFS)

Vase la figura 8.8 (pgina 305): muestra la arquitectura de NFS de Sun. Aunque NFS fue desarrollado inicialmente
para UNIX, es independiente del SO.
El mdulo servidor NFS est en el ncleo de cada computador que acta como servidor NFS. Las solicitudes
referentes a archivos remotos se traducen en el mdulo cliente a operaciones del protocolo NFS y se trasladan al
mdulo servidor NFS en el computador donde resida el archivo.
Estos mdulos se comunican entre ellos mediante el sistema RPC de Sun (puede configurarse para usarse bajo TCP
o UDP). Cualquier proceso puede enviar solicitudes a un servidor NFS, que sern ejecutadas si son vlidas y tienen
certificaciones vlidas del usuario.
SISTEMA DE ARCHIVOS VIRTUALES
NFS proporciona acceso transparente (ya sean los ficheros locales o remotos).
Se puede lograr la integracin de otros sistemas mediante un mdulo de sistema de archivos virtual (VFS), que se
aadi al ncleo de UNIX para distinguir entre archivos locales y remotos y para traducir los identificadores de
archivo usados por NFS a los identificadores de archivo interno usados en UNIX.
Los identificadores de archivo usados en NFS se llaman apuntadores de archivo (file handlers) y es opaco para los
clientes. Contiene toda la informacin necesaria para que el servidor distinga un archivo individual. Puede verse su
estructura en la pgina 306.
Una estructura VFS relaciona un sistema de archivos remoto con el directorio local en el que est montado. Si el
archivo es local, el v-nodo (ver explicacin en la pgina 306) contendr una referencia al ndice de archivo local; y si
es remoto, contendr un apuntador al archivo remoto.
INTEGRACIN DEL CLIENTE
El cliente NFS proporciona una interfaz para su uso por programas de aplicacin convencionales. Est integrado con
el ncleo y no proporcionado como una librera (a diferencia del mdulo cliente que habamos descrito hasta
ahora), de modo que los programas de usuario puedan acceder a los archivos con llamadas al sistema, que un nico
mdulo cliente sirva a todos los procesos del nivel del usuario con una cach compartida de los bloques utilizados
recientemente y que la clave de encriptacin usada para autenticar las ID de usuario pasadas al servidor puede
retenerse en el ncleo.
El mdulo cliente de NFS coopera con el VFS en cada mquina cliente.
CONTROL DE ACCESO Y AUTENTICACIN
El servidor NFS es sin estado (al contrario que el sistema de archivos de UNIX), por lo que no mantiene archivos
abiertos en nombre de sus clientes. Debe comprobar los permisos de acceso en cada solicitud, con informacin que
debe ser enviada por los clientes a cada vez. Antes, el cliente poda modificar las llamadas RPC para incluir el ID de
cualquier usuario, con lo que le suplantara; pero se resolvi con una opcin en el protocolo RPC para la
encriptacin de esta informacin. Actualmente, se integra Kerberos para proporcionar una solucin ms fuerte.
INTERFAZ DEL SERVIDOR NFS
En la Figura 8.9 (pgina 308) puede verse una representacin simplificada de la interfaz RPC del servidor NFS. Sus
operaciones mantienen una cierta similitud con las operaciones de los servicios de archivos planos y de directorios
descritos con anterioridad (en este, todas las operaciones se integran en un nico servicio).
Tenemos otras operaciones sobre directorios (create, remove, rename, link, symlink, readlink, mkdir, rmdir, readdir
y statfs), que son similares a sus equivalentes en UNIX (excepto readdir (mtodo independiente de la
representacin para leer el contenido de un directorio) y statfs (informacin del estado en los sistemas de archivos
remotos)).

SERVICIO DE MONTADO
El montado de los subrboles de los sistemas de archivos remotos por los clientes est soportado por un proceso de
servicio de montado separado que se ejecuta a nivel de usuario en cada computador servidor NFS. En cada uno de
ellos hay un archivo con un nombre bien conocido (/etc/exports) con los nombres de los sistemas de archivos
locales disponibles para montado remoto.
Los clientes usan una versin de la orden mount para este proceso sobre una mquina remota y una ruta concretas
a un nombre local. Se puede montar cualquier parte del rbol.
Puede verse un ejemplo en la Figura 8.10 (pgina 309).
Puede realizarse un montado rgido o un montado flexible. En el primer caso, el proceso se suspende hasta que
completa la solicitud (si falla el servidor, se sigue reintentando). En el segundo caso, el mdulo cliente NFS devuelve
una indicacin de fallo a los procesos de nivel de usuario despus de un pequeo nmero de reintentos.
Muchas instalaciones usan slo el montado rgido, ya que si no se detectan bien los errores, el comportamiento es
impredecible en montados flexibles. Pero slo con montado rgido, el programa no podr recuperarse si un servidor
NFS no est disponible durante un tiempo significativo.
TRADUCCIN DE UN NOMBRE DE RUTA
Los sistemas de archivos UNIX traducen nombres de ruta de archivo compuestos a referencias de i-nodo en las
llamadas open, create o stat.
En NFS no puede hacerse en el servidor, ya que el nombre puede cruzar un punto de montado en el cliente, los
directorios que mantienen diferentes partes de un nombre compuesto pueden residir en volmenes en diferentes
servidores; as que se realiza de forma interactiva por el cliente.
Cada parte del nombre de ruta se traduce al apuntador del archivo mediante una solicitud lookup. Este apuntador
se usa como parmetro en el siguiente lookup, de forma que se va componiendo consecutivamente.
AUTOMONTADOR
Sirve para montar un directorio remoto cuando se referencia un punto de montado vaco. Tiene una tabla de
puntos de montado vinculados a una o ms servidores NFS.
Si se intenta resolver un nombre de ruta que tenga uno o ms de estos puntos, se hace una llamada a lookup() al
automontador local para obtener los servidores correspondientes. Se usar el primero de ellos que responda a una
llamada. Se realiza con un enlace simblico, por lo que no se precisa otras solicitudes al automontador (si no se
accede en un determinado tiempo, se desmonta automticamente); aunque las ltimas implementaciones realizan
montados reales.
CACH EN EL SERVIDOR
Es indispensable en las implementaciones NFS. En los sistemas UNIX convencionales; los archivos, directorios o
atributos ledos se guardan en un cache buffer de la memoria principal para acceder ms rpidamente de nuevo a
ellas. Si se precisa escribir, se mantienen los cambios en el buffer hasta que haya que desalojarlo, momento en que
se graba en el disco (escritura retardada).
Los servidores NFS usan la cach en la mquina de servidor como se usa para otros accesos a archivos. En
operaciones de escritura, hay que asegurarse de que los resultados son persistentes.
Para ello, se puede usar la escritura a travs (se almacena en la cache y se pasa a disco antes de enviar respuesta al
cliente) o grabar en el disco cuando se realice una orden commit. Los clientes de NFS estndar usan este ltimo
modo (emiten un commit cuando se cierra un archivo abierto para escritura).

CACH EN EL CLIENTE
La usa para los resultados de read, write, getattr, lookup y readdir, con lo que disminuye el nmero de solicitudes al
servidor. Tngase en cuenta que el archivo remoto no queda actualizado an, por lo que los clientes deben sondear
al servidor para asegurarse de que se mantienen los datos que supone el proceso. Para ello se usan marcas de
tiempo (vase el procesos y la frmula en la pgina 312).
En cuanto a las escrituras, se marca la pgina modificada como sucia y se marca para volcarse asncronamente al
servidor cuando se cierra el archivo u ocurre un sync en el cliente. No garantiza la misma garanta de persistencia
que la cach en el servidor, pero emula el comportamiento para escrituras locales.
Para las lecturas de la entrada y escrituras retardadas, se incluyen uno o ms procesos bio-demonio en cada cliente
(un demonio es un proceso a nivel de usuario que realizan tareas del sistema, bio significa block input-output). Tras
una solicitud se avisa al bio-demonio, que solicita la transferencia del siguiente bloque desde el servidor a la cach
del cliente. Para escrituras, el bio-demonio enva un bloque al servidor cuando se haya llenado un bloque una
operacin del cliente.
As, el mdulo cliente no se bloquea esperando la vuelta de las operaciones.
OTRAS OPTIMIZACIONES
NFS est basado en el Sistema Rpido de Archivos (FFS) de UNIX BSD, que usa bloques de disco de 8 KB. Los
paquetes UDP usados para la implementacin de Sun RPC se extienden a 9 KB, con lo que una llamada RPC con un
bloque entero como argumento puede ser transferida en un solo paquete.
En la versin 3 de NFS no hay lmite de tamao para los bloques de archivo mantenidos en las operaciones read y
write, con lo que se pueden negociar tamaos mayores de 8 KB.
HACIENDO SEGURO NFS CON KERBEROS
En la implementacin estndar original de NFS, la identidad del usuario se inclua en cada solicitud mediante un
identificador numrico no encriptado y no se realizaba ninguna otra comprobacin de la autenticidad, por lo que
implicaba un alto grado de confianza en la integridad del computador cliente.
Kerberos intenta reducir lo mximo posible el nmero de componentes en los que haya que depositar confianza. Al
utilizar NFS en un entorno con Kerberos, slo se aceptarn solicitudes de clientes cuya identidad pueda ser
comprobada que ha sido autenticada por Kerberos.
Como NFS est implementado como un servidor sin estado, hay que enviar las credenciales con la solicitud, lo que
se considera demasiado costoso por el tiempo requerido para las encriptaciones necesarias y teniendo en cuenta
que habra que aadir la biblioteca cliente Kerberos al ncleo de todas las estaciones de trabajo.
En vez de eso, los resultados de la autenticacin (incluyendo el identificador numrico del usuario y la direccin del
computador cliente) se retienen en el servidor con la informacin de montado de cada volumen (el servidor NFS no
retiene el estado de los procesos individuales cliente, sino los montados actuales en cada computador cliente).
En cada solicitud, el servidor NFS comprueba el identificador y la direccin y permite el acceso si coinciden con los
almacenados en el servidor para el cliente relevante en el tiempo de montado.
Este mtodo es seguro para la mayora de formas de ataque. Slo un usuario en el tiempo puede entrar en cada
computador del cliente.
PRESTACIONES
El uso de NFS no impone una penalizacin de las prestaciones, teniendo identificadas dos reas de problemas
restantes: el uso frecuente de getattr para buscar marcas de tiempo de los servidores para la validacin de la cach
y las prestaciones pobres de write al utilizar la escritura a travs en el servidor. Pero, al ser las escrituras en torno a
un 5% de todas las llamadas en las cargas de trabajo UNIX, es tolerable esto ltimo (excepto cuando se escriben

grandes archivos en el servidor). Sin embargo, la inclusin de commit mejora sustancialmente las prestaciones de
escritura en las versiones actuales de NFS.
El 50% de las llamadas al servidor son lookup, debido al mtodo de traduccin de nombres de ruta paso a paso.
En la pgina 314 pueden verse un resumen de las prestaciones para implementaciones del servidor NFS de
diferentes vendedores y variadas configuraciones hardware.
RESUMEN NFS
Debido a que en este documento ya se han plasmado los apuntes del tema, no se realizar aqu el resumen. Puede
leerse en las pginas 314, 315 y 316 del libro base.