Sistemas de Ficheros Distribuidos (SFD)

Un Sistema de Ficheros Distribuido (SFD) gestiona distintos dispositivos en diferentes nodos, ofreciendo a los usuarios la misma visión que un sistema de ficheros centralizado. Permite compartir información de forma transparente, con la misma visión desde cualquier máquina (espacio de nombres único). Comparte numerosos aspectos con los sistemas de ficheros centralizados, pero también presenta características específicas:

• Traducción de nombres que afecta a varios nodos.
• Caching que afecta a múltiples nodos.
• Aspectos de tolerancia a fallos.

Estructura del SDF

Generalmente, un SDF utiliza una arquitectura cliente-servidor con dos componentes principales:

• Servicio de Directorio (SD): Traduce nombres de fichero a un identificador interno.
• Servicio de Ficheros (SF): Proporciona acceso a los ficheros a partir de su identificador y gestiona un “sistema de ficheros plano”.

Existen dos alternativas de implementación:

• Único módulo: Ofrece ambos servicios (similar a UNIX), donde el servidor de ficheros incluye ambas funciones y el directorio es un fichero especial.
• Módulos independientes: (p. ej. Amoeba) con un servidor de directorios y un servidor de ficheros separados.

Servicio del Directorio

El esquema de nombres generalmente tiene dos niveles: nombres de usuario y nombres internos. El directorio relaciona los nombres de usuario con los nombres internos. Existen dos niveles de traducción:

• De nombre de usuario a interno (realizado por el Servicio de Directorio).
• De nombre interno a la localización del fichero.

El SD puede integrarse en un servicio de nombres genérico, gestionando no solo ficheros, sino todos los objetos del sistema.

Nombres del Usuario

Generalmente, el espacio de nombres es jerárquico, utilizando pathnames. Debe proporcionar transparencia de la posición, de modo que el nombre del fichero no revele su ubicación de almacenamiento ni la máquina donde reside.

Nombres Internos

Se utiliza un Identificador Único de Fichero (UFID) para la gestión interna. La independencia de la posición es crucial: el nombre del fichero no cambia si este migra. El nombre interno no incluye información de la máquina. Generalmente, se utilizan nombres estructurados para facilitar la generación y resolución de nombres internos.

Dominio de Nombre

El espacio de nombres se divide en dominios. El UFID se compone del UID del dominio y el UID dentro del dominio. Cada dominio es gestionado por un servidor de directorios, permitiendo la generación y resolución de nombres distribuida. Para generar IDs de dominio únicos, se puede usar, por ejemplo, la dirección IP del nodo creador y la fecha. La dirección IP solo asegura la unicidad del nombre, ya que el dominio puede migrar. Existen alternativas para la composición de dominios (“montaje”):

• Montaje en el cliente: Montar el sistema de ficheros remoto sobre la jerarquía local (NFS). Cada máquina tiene un espacio de nombres diferente.
• Montaje en el servidor: Único espacio de nombres en todas las máquinas (AFS).

Resolución de Nombres

La resolución de nombres de usuario a interno (realizada por el servicio de directorio) traduce un pathname y puede implicar a varios servidores de directorio. Existen diferentes alternativas:

• Resolución iterativa: El cliente contacta con los SDs sucesivamente.
• Resolución transitiva: El cliente contacta con el primer SD, este con el segundo, y el último SD responde (no adecuado para RPC).
• Resolución recursiva: El cliente contacta con el primer SD, este con el segundo, etc., y el primer SD responde al cliente.

Estas alternativas también son aplicables a un servicio de nombres genérico.

Uso de la Caché en la Resolución

El uso de caché en los nodos, guardando las últimas traducciones, reduce la necesidad de contactar con el SD, mejorando la eficiencia y la capacidad de crecimiento del sistema. La información en caché se trata como una “pista”, utilizando mecanismos para detectar traducciones inválidas. La resolución iterativa favorece el uso de la caché.

Localización de los Ficheros

Para localizar un fichero a partir de su UFID, se necesita traducir el ID de dominio al nodo donde está almacenado, lo cual solo es necesario si el ID de dominio no contiene la dirección del nodo. Existen diferentes esquemas de localización:

• Tablas que relacionan dominio-nodo.
• Uso de broadcast para localizar el nodo.
• Uso de “caché de localizaciones” en los clientes (la información en caché se trata como una “pista”).

Servicio de los Ficheros

Este servicio gestiona los ficheros y el acceso a los datos. Se analizan los siguientes aspectos:

• Uso de los ficheros.
• Semántica de utilización concurrente.
• Modelo de acceso.
• Caching.
• Servidor con o sin estado.

Uso de los Ficheros

La forma de usar los ficheros influye en el diseño de los SFD. Las estadísticas de uso en entornos UNIX de propósito general muestran que la mayoría de los ficheros son pequeños, las lecturas son más frecuentes que las escrituras, el acceso suele ser secuencial, muchos ficheros tienen una vida corta y la compartición es poco frecuente.

Semánticas del Uso Concurrente

Una sesión es una serie de accesos que realiza un cliente entre open y close. La semántica define el efecto de varios procesos accediendo simultáneamente al mismo fichero. Existen varias semánticas:

• Semántica UNIX (Sprite y DFS): Una lectura ve los efectos de todas las escrituras previas. El efecto de dos escrituras sucesivas es el de la última (difícil de implementar en sistemas distribuidos).
• Semántica de sesión (AFS): Los cambios a un fichero abierto son visibles solo en el proceso (nodo) que los realizó. Tras cerrar el fichero, los cambios son visibles en sesiones posteriores. Permite múltiples imágenes simultáneas del fichero. Si dos sesiones sobre el mismo fichero terminan concurrentemente, la última deja el resultado final. No es adecuada para procesos con acceso concurrente.
• Semántica de ficheros inmutables (Amoeba): El contenido de un fichero no puede modificarse, ni su nombre reutilizarse. Solo se puede compartir para lectura.
• Semántica de transacciones: Las operaciones sobre el fichero se encapsulan en una transacción (se estudia en un capítulo posterior).
• Sin semántica definida (NFS).

Modelo del Acceso

Existen dos modelos principales:

• Modelo carga/descarga: Transferencias completas del fichero. Se almacena localmente en memoria o disco. Normalmente utiliza semántica de sesión. Ofrece eficiencia en las transferencias, pero la llamada open tiene mucha latencia.
• Modelo de servicio remoto: El servidor proporciona todas las operaciones sobre el fichero, con acceso por bloques. Sigue el modelo cliente/servidor.

Caching

El caching mejora el rendimiento, explotando la proximidad temporal y espacial de las referencias, y permitiendo lecturas adelantadas. Mejora el rendimiento de las lecturas, sobre todo secuenciales, y las escrituras diferidas mejoran el rendimiento de las escrituras. Existen otros tipos de caché, como la caché de nombres y la de metadatos. La caché puede ubicarse en los servidores (reduce accesos a disco) o en los clientes (reduce el tráfico de red, la carga en los servidores y mejora la capacidad de crecimiento, pero introduce problemas de coherencia). En los clientes, la caché puede estar en disco local (más capacidad, más lento, no volátil) o en memoria principal (menos capacidad, más rápido, volátil).

Política de Actualización

• Escritura inmediata (write-through): Ofrece buena fiabilidad, pero las escrituras son más lentas.
• Escritura diferida (delayed-write): Escrituras más rápidas y menor tráfico de red, pero menor fiabilidad. Existen alternativas para el volcado de datos: volcado periódico o write-on-close.

Coherencia de Caché

El uso de caché en clientes introduce problemas de coherencia. Existen dos estrategias principales:

• Validación iniciada por el cliente: El cliente contacta con el servidor para validar la caché en cada acceso, al abrir el fichero o periódicamente.
• Validación iniciada por el servidor: El servidor avisa al cliente cuando su copia es inválida (generalmente se usa write-invalidate). El servidor registra qué ficheros guarda cada cliente. La granularidad puede ser a nivel de fichero o de bloque.

Servidores con Estado y sin Estado

Esta alternativa de diseño influye en la tolerancia a fallos. Los servidores con estado mantienen información sobre los clientes. Al abrir un fichero, el servidor guarda información y da al cliente un identificador único. Los servidores sin estado no guardan información del cliente; cada petición es autocontenida. Las ventajas de los servidores con estado son: mensajes de petición más cortos, mejor rendimiento, facilitan la lectura adelantada. Son necesarios para la validación iniciada por el servidor. El uso de leases (permisos con plazo de expiración) mitiga el problema. Las ventajas de los servidores sin estado son: mayor tolerancia a fallos, no necesitan open ni close (menos mensajes), no gastan memoria en el servidor.

Network File System (NFS) de Sun

NFS es un protocolo estándar para el acceso a ficheros remotos, diseñado para entornos heterogéneos. Utiliza RPC/XDR para la independencia y su seguridad se basa en RPC (autenticación por claves). La compartición se realiza montando un directorio remoto en el sistema de ficheros local. El espacio de nombres es diferente en cada máquina. El montaje no es transparente (se indica la máquina remota), pero el acceso a los ficheros, una vez montado, sí lo es. No es un verdadero sistema de ficheros distribuido. NFS comprende dos protocolos: el protocolo de montaje y el protocolo de acceso a ficheros (protocolo NFS).

Protocolo de Montaje

Establece una conexión lógica entre el servidor y el cliente. Cada máquina tiene una “lista de exportación” que define qué directorios exporta y quién puede montarlos. La petición de montaje incluye la máquina y el directorio remotos, convirtiéndose en una RPC al servidor de montaje remoto. Si el permiso está en la lista, se devuelve un identificador “opaco” (handle). En UNIX, este identificador corresponde al sistema de ficheros y al nodo-i del directorio montado. La operación de montaje solo afecta al cliente, no al servidor. Se permiten montajes NFS anidados, pero no “transitivos”. Algunas implementaciones ofrecen montajes hard o soft y automontaje.