PDF de programación - Sistemas de ficheros distribuidos - Sistemas Distribuidos

Sistemas Distribuidos

Sistemas Distribuidos

Sistemas de
Sistemas de
ficheros
ficheros
distribuidos
distribuidos

Índice

Introducción

•
• Estructura de un SFD
• Resolución de nombres
• Acceso a los datos
• Gestión de cache
• Gestión de cerrojos
• Estudio de ejemplos: NFS, AFS y Coda
• Sistemas de ficheros paralelos

– General Parallel File System (GPFS)
– Google File System (GFS)

Sistemas Distribuidos
2

Fernando Pérez Costoya

Conceptos básicos

Características deseables del SFD

• Sistema de ficheros distribuido (SFD)

– Sistema de ficheros para sistema distribuido
– Gestiona distintos dispositivos en diferentes nodos ofreciendo a

usuarios la misma visión que un SF centralizado

– Permite que usuarios compartan información de forma transparente
– Misma visión desde cualquier máquina

• Numerosos aspectos similares a SF centralizados
• Algunos aspectos específicos como por ejemplo:

– Traducción de nombres involucra a varios nodos
– Uso de cache afecta a múltiples nodos
– Aspectos de tolerancia a fallos

• Aplicables las correspondientes al SD global:

– Transparencia, fiabilidad, rendimiento, escalabilidad, seguridad.

• Específicamente:

– Espacio de nombres único
– Soporte de migración de ficheros
– Soporte para replicación
– Capacidad para operar en sistemas “desconectados”

• Una red “partida” o un cliente que usa un sistema portátil

– Soporte de heterogeneidad en hardware y S.O.
– Integración de nuevos esquemas de almacenamiento (SAN)
– Paralelismo en acceso a datos de un fichero

Sistemas Distribuidos
3

Fernando Pérez Costoya

Sistemas Distribuidos
4

Fernando Pérez Costoya

4-Sistemas de ficheros distribuidos

1

Sistemas Distribuidos

Estructura del SFD

Arquitectura del SFD

• Cliente (nodo con aplicación) – Servidor (nodo con disco)
• ¿Cómo repartir funcionalidad de SF entre cliente y servidor?
• Arquitectura “tradicional”

– servidor: proporciona acceso a ficheros almacenados en sus discos
– cliente: pasarela entre aplicación y servidor

• con más o menos funcionalidad (clientes fat o thin)

• Arquitectura “alternativa”

– servidor: proporciona acceso a bloques de disco
– cliente: toda la funcionalidad del SF
– Utilizada en sistemas de ficheros para clusters

• se estudiará más adelante

• Solución basada en arquitectura tradicional parece sencilla:

– SF convencional en servidor
– Exporta servicios locales para abrir, cerrar, leer, escribir, cerrojos,...

• ¿Asunto zanjado? No todo está resuelto:

– Resolución de nombre de fichero:

• Cliente y varios servidores involucrados. ¿Cómo se reparten trabajo?

– Acceso a los datos:

• ¿se transfiere sólo lo pedido? ¿más cantidad? ¿todo el fichero?
• Uso de cache en el cliente. Coherencia entre múltiples caches.

– Gestión de cerrojos:

• ¿Qué hacer si se cae un cliente en posesión de un cerrojo?

– Otros: migración, replicación, heterogeneidad, ...

Sistemas Distribuidos
5

Fernando Pérez Costoya

Sistemas Distribuidos
6

Fernando Pérez Costoya

Operaciones sobre los ficheros

Gestión de nombres

• Apertura del fichero: Traducción del nombre

– Gestión de nombres

• Lecturas/escrituras sobre el fichero

– Acceso a datos
– Uso de cache

• Establecimiento de cerrojos sobre el fichero

• Similar a SF convencionales:

– Espacio de nombres jerárquico basado en directorios
– Esquema de nombres con dos niveles:
– Directorio: Relaciona nombres de usuario con internos

• Nombres de usuario (pathname) y Nombres internos

• Nombres de usuario

– Deben proporcionar transparencia de la posición

• Nombre no debe incluir identificación del nodo donde está

triqui.fi.upm.es:/home/fichero.txt

• Nombres internos

– Identificador único de fichero (UFID) utilizado por el sistema

• Puede ser una extensión del usado en SF convencionales.
• Por ejemplo:

id. de máquina + id. disco + id. partición + id. inodo

Sistemas Distribuidos
7

Fernando Pérez Costoya

Sistemas Distribuidos
8

Fernando Pérez Costoya

4-Sistemas de ficheros distribuidos

2

Sistemas Distribuidos

Espacio de nombres

Resolución de nombres

• Similar a SF convencionales:

– Espacio de nombres dividido en volúmenes (o particiones, o ...)

• Cada volumen gestionado por un servidor

– Espacio único mediante composición de volúmenes:
• Extensión distribuida de operación de montaje de UNIX

• Alternativas en la composición:

– Montar sistema de ficheros remoto sobre la jerarquía local (NFS)
• Montaje en cliente: información de montaje se almacena en cliente
• Espacio de nombres diferente en cada máquina

– Único espacio de nombres en todas las máquinas (AFS)

• Montaje en servidor: información de montaje se almacena en servidor
• Espacio de nombres común para el SD

• Traducir una ruta que se extiende por varios servidores
• ¿Quién busca cada componente de la ruta?

– cliente: solicita contenido del directorio al servidor y busca (AFS)
– servidor: realiza parte de la búsqueda que le concierne

•

• Alternativas en la resolución dirigida por los servidores

– iterativa, transitiva y recursiva
“Cache de nombres” en clientes
– Almacén de relaciones entre rutas y nombres internos
• También existe en SF convencional
– Evita repetir proceso de resolución
– Necesidad de coherencia

• Operación más rápida y menor consumo de red (escalabilidad)

• Fichero borrado y nombre interno reutilizado
• Uso de contador de versión del inodo

id. de máquina + id. disco + id. partición + id. inodo + nº versión

Sistemas Distribuidos
9

Fernando Pérez Costoya

Sistemas Distribuidos
10

Fernando Pérez Costoya

Resolución iterativa

Resolución transitiva

C

1/2

3/4

5/6

SD1

SD2

SD3

C

1

4

SD1

2

3

SD2

SD3

Sistemas Distribuidos
11

Fernando Pérez Costoya

Sistemas Distribuidos
12

Fernando Pérez Costoya

4-Sistemas de ficheros distribuidos

3

Sistemas Distribuidos

Resolución recursiva

Localización de ficheros

1/6

C

SD1

SD2

SD3

2

3

5

4

• Resolución obtiene nombre interno (UFID)
• Uso de UFID con dir. máquina donde fichero está localizado

– No proporciona, en principio, independencia de la posición

• Nombre de fichero cambia cuando éste migra

• Uso de UFID que no contenga información de máquina:

id. único de volumen + id. inodo + nº versión

– Por ejemplo (AFS):
– Permite migración de volúmenes
– Requiere esquema de localización: Volumen → Máquina

• Posibles esquemas de localización:
– Tablas que mantengan la información de ubicación (AFS)
– Uso de broadcast para localizar nodo

• Uso de “cache de localizaciones” en clientes

Sistemas Distribuidos
13

Fernando Pérez Costoya

Sistemas Distribuidos
14

Fernando Pérez Costoya

Acceso a datos del fichero

Semánticas de uso concurrente

• Una vez abierto el fichero, se tiene info. para acceder al mismo
• Aspectos de diseño vinculados con acceso a datos:

– ¿Qué se garantiza ante accesos concurrentes?

• Semántica de uso concurrente

– ¿Qué información se transfiere entre cliente y servidor?

– ¿Qué info. se guarda en cache y cómo se gestiona?

• Modelo de acceso

• Gestión de cache

• Sesión: serie de accesos que realiza cliente entre open y close
• La semántica especifica el efecto de varios procesos

accediendo de forma simultánea al mismo fichero

• Semántica UNIX

– Una lectura ve los efectos de todas las escrituras previas
– El efecto de dos escrituras sucesivas es el de la última

• Semántica de sesión (AFS)

– Cambios a fichero abierto, visibles sólo en nodo que lo modificó
– Una vez cerrado, cambios visibles sólo en sesiones posteriores
– Múltiples imágenes simultáneas del fichero
– Dos sesiones sobre mismo fichero que terminan concurrentemente:
– No adecuada para procesos con acceso concurrente a un fichero

• La última deja el resultado final

Sistemas Distribuidos
15

Fernando Pérez Costoya

Sistemas Distribuidos
16

Fernando Pérez Costoya

4-Sistemas de ficheros distribuidos

4

Sistemas Distribuidos

Modelo de acceso

• Modelo carga/descarga

– Transferencias completas del fichero
– Localmente se almacena en memoria o discos locales
– Normalmente utiliza semántica de sesión
– Eficiencia en las transferencias
– Llamada open con mucha latencia

• Modelo de servicio remoto

– Servidor debe proporcionar todas las operaciones sobre el fichero
– Acceso por bloques
– Modelo cliente/servidor

Modelo carga/descarga

• Correspondencia petic. de aplicación y mens. de protocolo:

– open → mensaje de descarga (download)

• se realiza traducción y servidor envía fichero completo
• cliente almacena fichero en cache local

– read/write/lseek → no implica mensajes de protocolo

• lecturas y escrituras sobre copia local
– close → mensaje de carga (upload)

• si se ha modificado, se envía fichero completo al servidor

Sistemas Distribuidos
17

Fernando Pérez Costoya

Sistemas Distribuidos
18

Fernando Pérez Costoya

Modelo de serv. remoto: con estado
• Correspondencia petic. de aplicación y mens. de protocolo:

– open → mensaje de apertura

• se realiza traducción
• servidor habilita zona de memoria para info. de la sesión
• retorna id. específico para esa sesión

– read/write/lseek → mensaje de protocolo correspondiente
• mensaje incluye id. sesión
• mensaje lectura y escritura incluye tamaño pero no posición
• uso de información sobre la sesión almacenada en servidor (posición)

– close → mensaje de cierre

• servidor libera zona de memoria de la sesión

• Ventajas servicio con estado (frente a sin estado):

– Mensajes más pequeños, posibilidad de realizar políticas

“inteligentes” en servidor (p.ej. lectura anticipada), procesamiento
de peticiones posiblemente un poco más eficiente

Modelo de serv. remoto: sin estado

• Correspondencia petic. de aplicación y mens. de protocolo:

– open → mensaje de apertura

• se realiza traducción
• servidor no habilita zona de memoria para info. de sesión (cliente sí)
• retorna id. interno del fichero UFID

– read/write → mensaje de protocolo correspondiente

• mensaje autocontenido
• mensaje incluye UFID, tamaño y posición
– lseek → no implica mensaje de protocolo
– close → no implica mensaje de protoc