Sistemas de Archivos
Distribuidos
Por:
Castorani, Carlos
Correa, Fabian
De Sousa, Christian
Pereira, José Manuel
Walzer, Carlos
CI-4821. Sistemas de Operación II
Universidad Simón Bolívar, 28 septiembre 2005
Sistemas de Archivos
Distribuidos
Índice
1. Introducción
1.1 Características de los Sistemas de
Archivo.
1.2 Requerimientos de los Sistemas de Archivos
Distribuidos.
2. Arquitectura del Sistema de Archivos
3. Sun Network File System
3.1 El Paradigma y su optimalidad.
4. The Andrew File System
4.1 El Paradigma y su optimalidad.
5. Comparación
6. Conclusiones: Mejoras.
Sistemas de Archivos Distribuidos
1. Introducción
Los sistemas de archivo distribuidos permiten almacenar y
acceder archivos remotos de la misma manera como si
fueran locales, permitiendo que el usuario haga uso de los
archivos de cualquier computador en una red.
El desempeño y confiabilidad son las principales
características y se deben poder comparar con el rendimiento
y manejo local.
En este trabajo describiremos una arquitectura simple de un
Sistema de archivos y presentaremos las implementaciones
de
Sun Network File System, NFS
y The Andrew Network File System.
Cada uno de estos emula la interfaz del sistema de archivos
de UNIX con distintos niveles de escalabilidad, tolerancia a
fallos y semántica de actualizaciones.
CI-4821, sep-dic 2005
Sistemas de Archivos Distribuidos
Figura 1. Tipos de sistemas de almacenamiento
Sharing Persis- Distributed
Consistency Example
tence
cache/replicas maintenance
Main memory
1
RAM
File system
1
UNIX file system
Distributed file system
Sun NFS
Web
Web server
Distributed shared memory
Ivy
Remote objects (RMI/ORB)
1
CORBA
Persistent object store
1
CORBA Persistent
Object Service
Peer-to-peer storage system
2
OceanStore
Tipos de Consistencia:
1: Sólo una copia. : Garantías ligeramente débiles. 2: Garantías considerablemente débiles.
CI-4821, sep-dic 2005
Sistemas de Archivos Distribuidos
Figura 2. Estructura de Módulos
1. Introducción
1.1. Características
de los Sistemas
de Archivo.
Director y module:
r elates file names to file IDs
File module:
r elates file IDs to particular f iles
Access contr ol module:
checks per mission for operation r equested
File access module:
r eads or w rites f ile data or attributes
Block module:
accesses and allocates disk blocks
Device module:
disk I/O and buff er ing
CI-4821, sep-dic 2005
Sistemas de Archivos Distribuidos
Figura 3. Operaciones del sistema de Archivos de UNIX
filedes = open(name, mode)
filedes = creat(name, mode)
status = close(filedes)
count = read(filedes, buffer, n)
count = write(filedes, buffer, n)
pos = lseek(filedes, offset,
whence)
status = unlink(name)
status = link(name1, name2)
status = stat(name, buffer)
CI-4821, sep-dic 2005
Opens an existing file with the given name.
Creates a new file with the given name.
Both operations deliver a file descriptor referencing the open
file. The mode is read, write or both.
Closes the open file filedes.
Transfers n bytes from the file referenced by filedes to buffer.
Transfers n bytes to the file referenced by filedes from buffer.
Both operations deliver the number of bytes actually transferred
and advance the read-write pointer.
Moves the read-write pointer to offset (relative or absolute,
depending on whence).
Removes the file name from the directory structure. If the file
has no other names, it is deleted.
Adds a new name (name2) for a file (name1).
Gets the file attributes for file name into buffer.
Sistemas de Archivos Distribuidos
1. Introducción
1.1. Características
de los Sistemas
de Archivo.
1.2. Requerimiento
de los Sistemas
de Archivos
Distribuidos.
CI-4821, sep-dic 2005
a. Transparencia.
Se debe balancear la flexibilidad y la escalabilidad que
derivan de la transparencia, contra la complejidad del
software y el desempeño.
Acceso: Los programas del cliente deben
desconocer la distribución de los archivos. Un simple
conjunto de operaciones debe proveer el acceso local y
remoto. Programas escritos para operar en archivos
locales deben se capaces de acceder archivos remotos sin
modificaciones.
Localidad: Los programas del cliente deben ver
un espacio de nombres de archivos uniforme. Los archivos
podrán ser reubicados sin cambiar la ruta de sus nombres.
Movilidad: Ni los programas de los clientes ni las
tablas de administración del sistema necesitarán ser
cambiadas cuando los archivos son movidos. Esto permite
la movilidad de archivos – volumenes completos pueden
ser movidos, por el administrador del sistema o
automaticamente
Sistemas de Archivos Distribuidos
1. Introducción
1.1. Características
de los Sistemas
de Archivo.
1.2. Requerimiento
de los Sistemas
de Archivos
Distribuidos.
…a.Transparencia.
Desempeño: Los programas del cliente deben
continuar desempeñándose satisfactoriamente mientras la
carga del servidor varíe en un rango específico.
Escalabilidad: El servicio puede expandirse con un
crecimiento que maneje un alto rango de cargas y tamaños
de las redes.
b. Actualización Concurrente de Archivos.
Cambios a un archivo por parte de un cliente, no debe
interferir con las operaciones de otros clientes que
simultáneamente acceden el mismo archivo.(control de
concurrencia)
c. Archivos replicados.
Un archivo debe ser representado por varias copias de su
contenido en distintas localidades.
CI-4821, sep-dic 2005
Sistemas de Archivos Distribuidos
1. Introducción
1.1. Características
de los Sistemas
de Archivo.
1.2. Requerimiento
de los Sistemas
de Archivos
Distribuidos.
d. Sistemas Heterogéneos
El servicio debe ser definido de manera que el cliente y el
servidor puedan ser implementados por diferentes sistemas
de operación y computadores.
e. Tolerancia a Fallas
Es esencial que el sistema continúe funcionando en el caso
de que el cliente o el servidor fallen.
f. Consistencia
Unix one-copy update semantics. Cuando los archivos son
replicados o colocados en cache en distintas localidades,
existe un retraso inevitable en la propagación de las
modificaciones que puede derivar en problemas de
consistencia.
CI-4821, sep-dic 2005
Sistemas de Archivos Distribuidos
1. Introducción
1.1. Características
de los Sistemas
de Archivo.
1.2. Requerimiento
de los Sistemas
de Archivos
Distribuidos.
CI-4821, sep-dic 2005
g. Seguridad.
En sistemas distribuidos existe la necesidad de autenticar la
petición del cliente. Además protege el contenido de los
mensajes de petición y respuesta con firmas digitales y
encriptamiento.
h. Eficiencia.
Apegados lo más posible a los sistemas de archivos
convencionales: con desempeño comparable.
Sistemas de Archivos Distribuidos
Figura 4. Arquitectura del sistema de archivos
2. Arquitectura
del Sistema
de Archivos
Client computer
Application Application
program
program
Server computer
Directory service
Flat file service
Client module
CI-4821, sep-dic 2005
Sistemas de Archivos Distribuidos
2. Arquitectura
del Sistema
de Archivos
CI-4821, sep-dic 2005
a. Flat File Service.
Se encarga de implementar operaciones sobre el
contenido de los archivos.
b. Directory Service
Provee el mapeo entre nombres de texto para archivos y
sus UFIDs (Unique file Identifier). Provee funciones
necesarias para generar directorios.
c. Client Module
Corre en cada cliente, integrando y extendiendo las
operaciones de el flat file service y el directory service
bajo una aplicación simple que esta disponible a nivel de
usuario en el cliente.
d. Flat File Service Interface
Esta es la interfaz de RPC usada por los módulos del
cliente. Normalmente usada directamente por
programas a nivel de usuario. La Figura 5, contiene la
definición de la interfaz para el flat file service.
Sistemas de Archivos Distribuidos
Figura 5. Arquitectura del sistema de archivos
2. Arquitectura
del Sistema
de Archivos
Read(FileId, i, n) -> Data
— throws BadPosition
Write(FileId, i, Data)
— throws BadPosition
Create() -> FileId
Delete(FileId)
GetAttributes(FileId) -> Attr
SetAttributes(FileId, Attr)
CI-4821, sep-dic 2005
If 1 ≤ i ≤ Length(File): Reads a sequence of up to n items
from a file starting at item i and returns it in Data.
If 1 ≤ i ≤ Length(File)+1: Writes a sequence of Data to a
file, starting at item i, extending the file if necessary.
Creates a new file of length 0 and delivers a UFID for it.
Removes the file from the file store.
Returns the file attributes for the file.
Sets the file attributes (only those attributes that are not
shaded in Figure 8.3).
Sistemas de Archivos Distribuidos
2. Arquitectura
del Sistema
de Archivos
e. Access control
Los permisos de acceso del cliente, en UFS, son
chequeados con el modo de acceso pedido (read o
write) en la llamada abierta.
En implementaciones distribuidas, el chequeo de los
permisos de acceso deben ser realizados en el servidor,
ya que sino la interfaz del servidor RPC sería un punto
de acceso desprotegido.
f. Directory Service Interface
Su principal función es proveer un servicio para traducir
los nombres de texto a UFID. Para esto, mantiene
archivos de directorios que contienen el mapeo entre
nombre de texto y UFID.
La Figura 6, contiene una definición de la interfaz del
RPC al servicio de directorio.
CI-4821, sep-dic 2005
Sistemas de Archivos Distribuidos
Figura 6. Operaciones del servicio de Directorio
2. Arquitectura
del Sistema
de Archivos
Lookup(Dir, Name) -> FileId
— throws NotFound
AddName(Dir, Name, FileId)
— throws NameDuplicate
UnName(Dir, Name)
— throws NotFound
GetNames(Dir, Pattern) -> NameSeq
CI-4821, sep-dic 2005
Locates the text name in the directory and returns the
relevant UFID. If Name is not in the directory, throws an
exception.
If Name is not in the directory, adds (Name, File) to the
directory and updates the file’s attribute record.
If Name is already in the directory: throws an exception.
If Name is in the directory: the entry containing Name is
removed from the directory.
If Name is not in the directory: throws an exception.
Returns all the text names in the directory that match the
regular expression Pattern.
Sistemas de Archivos Distribuidos
2. Arquitectura
del Sistema
de Archivos
g. Hierarchic File System
UNIX provee un número de directorios con una
estructura tipo árbol.
Una red con estructura de directorios tipo árbol, está
construida con archivos en las hojas y directorios en los
otros nodos del árbol. La raíz es un directorio con un
UFID “bien conocido”.
h. File Groups
Es una colección de archivos localizados en un servidor
dado. Pueden ser movidos entre servidores, pero un
archivo no puede cambiarse del grupo al que pertenece.
32bits
identificador del
Grupo de archivos
CI-4821, sep-dic 2005
IP address
16bits
date
Sistemas de Archivos Distribuidos
3. Sun File
System
Todas las implementaciones de NFS soportan el protocolo
NFS – un conjunto de llamadas a procedimientos que
proceen el medio para que los clientes desempeñen
operaciones sobre un sistema de almacenamiento de
archivo remoto - .Es sistema-operativo-independiente, pero
fue inicialmente desarrollado para ser usado en sistemas
de redes UNIX.
El módulo del servidor NFS reside en el kernel de cada
computador que actúa como un servidor NFS. Peticiones
que se refieren a archivos en un sistemas de archivos
remotos, son traducidos por el módulo del cliente a
operaciones de protocolo NFS y luego pasadas al módulo
del servidor NFS en el computador que posee el sistema
de archivos correspondiente.
La Figura 7 muestra la arquitectura de Sun NFS.
CI-4821, sep-dic 2005
Sistemas de Archivos Distribuidos
Figura 7. Operaciones del servicio de Directorio
Client computer
Server computer
Application Application
program
program
UNIX
system calls
UNIX kernel
UNIX kernel
Virtual file system
UNIX
file
system
CI-4821, sep-dic 2005
Remote
Other
file system
Local
Virtual file system
NFS
client
NFS
server
NFS
protocol
UNIX
file
system
Sistemas de Archivos Distribuidos
3. Sun File
System
Sistema de Archivo Virtual
La integración se da gracias al módulo del sistema de
archivo virtual (virtual file system – VFS), que ha sido
agregado al kernel de UNIX para distinguir entre archivos
locales y remotos y para traducir entre el identificador de
archivos independiente de UNIX usado por NFS y el
identificador de archivos interno normalmente usado por
UNIX y otros sistemas de archivos.
El identificador de archivos usado en NFS es llamado file
handles. No es visible al cliente y contiene la información
que el servidor requiere para distinguir un archivo
individual.
Utiliza vnodes ( virtual node ) para indicar si un archivo
abierto es local o remoto. Hace referencia a un inode (
UNIX ) o un rnode ( remote node )
CI-4821, sep-dic 2005
Sistemas de Archivos Distribuidos
3. Sun File
System
Integración del Cliente
El módulo del cliente NFS juega el rol descrito para el
módulo en nuestro modelo de arquitectura.
Permite una interfaz para se usado por aplicaciones
convencionales
Sin embargo, nuestro modelo emula la semántica de las
primitivas del sistema de archivos estándar de UNIX y está
integrado a su kernel.
Tiene ventajas usarlo en el Kernel y no como una libreria
CI-4821, sep-dic 2005
Sistemas de Archivos Distribuidos
3. Sun File
System
Autenticación y control de acceso
A diferencia de los sistemas de archivo convencionales de
UNIX, el servidor NFS es Sin Estados y no deja archivos
abiertos del lado del servidor.
El protocolo RPC de SUN exige que los clientes envíen la
información de autenticación con cada petición y esto es
chequeado con los permisos de acceso en los atributos de
los archivos.
Ya que un servidor NFS provee una interfaz RPC
convencional en un puerto “bien conocido”, esto puede
crear un hueco en la seguridad ya que cualquier proceso
se puede comportar como cliente.
CI-4821, sep-dic 2005
La integración de NFS con Kerberos, provee una solución
más fuerte y comprensiva sobre los problemas de
autenticación de usuario y seguridad.
Sistemas de Archivos Distribuidos
Figura 8. Operaciones del servidor NFS – 1
lookup(dirfh, name) -> fh, attr
Returns file handle and attributes for the file name in the directory
dirfh.
create(dirfh, name, attr) ->
newfh, attr
Creates a new file name in directory dirfh with attributes attr and
returns the new file handle and attributes.
remove(dirfh, name) status
Removes file name from directory dirfh.
getattr(fh) -> attr
Returns file attributes of file fh. (Similar to the UNIX stat system
call.)
setattr(fh, attr) -> attr
Sets the attributes (mode, user id, group id, size, access time and
modify time of a file). Setting the size to 0 truncates the file.
read(fh, offset, count) -> attr, data
Returns up to count bytes of data from a file starting at offset.
Also returns the latest attributes of the file.
write(fh, offset, count, data) -> attr
Writes count bytes of data to a file starting at offset. Returns the
attributes of the file after the write has taken place.
rename(dirfh, name, todirfh, toname) Changes the name of file name in directory dirfh to toname in
-> status
directory to todirfh
.
link(newdirfh, newname, dirfh, name) Creates an entry newname in the directory newdirfh which refers to
-> status
file name in the directory dirfh.
Continúa en la próxima lámina…
CI-4821, sep-dic 2005
Sistemas de Archivos Distribuidos
Figura 8. Operaciones del servidor NFS – 2
symlink(newdirfh, newname, string)
-> status
Creates an entry newname in the directory newdirfh of type
symbolic link with the value string. The server does not interpret
the string but makes a symbolic link file to hold it.
readlink(fh) -> string
Returns the string that is associated with the symbolic link file
identified by fh.
mkdir(dirfh, name, attr) ->
newfh, attr
Creates a new directory name with attributes attr and returns the
new file handle and attributes.
rmdir(dirfh, name) -> status
Removes the empty directory name from the parent directory dirfh.
Fails if the directory is not empty.
readdir(dirfh, cookie, count) ->
entries
Returns up to count bytes of directory entries from the directory
dirfh. Each entry contains a file name, a file handle, and an opaque
pointer to the next directory entry, called a cookie. The cookie is
used in subsequent readdir calls to start reading from the following
entry. If the value of cookie is 0, reads from the first entry in the
directory.
statfs(fh) -> fsstats
Returns file system information (such as block size, number of
free blocks and so on) for the file system containing a file fh.
CI-4821, sep-dic 2005
Sistemas de Archivos Distribuidos
3. Sun File
System
Interfaz del servidor NFS
Las operaciones de acceso a archivos read, write, getattr y
setattr; son casi idénticas a las operaciones definidas por
nuestro modelo de servicios Flat File. Ver figuras 5,6,8.
Las operaciones sobre archivos y directorios están
integradas en un solo servicio. La creación e inserción de
archivos en directorios es realizada por la misma operación
create.
El resto de las operaciones sobre directorios son similares
a su contraparte en UNIX: remove, rename link, symlink,
readink, mkdir, rmdir, readdir y statfs; a diferencia de
readdir, que provee una representación independiente al
leer directorios y statfs: que da el status sobre el sistema
de archivos remoto.
CI-4821, sep-dic 2005
Sistemas de Archivos Distribuidos
3. Sun File
System
Servicio Mount
Es un servicio separado que corre a nivel de usuario en
cada servidor NFS. En cada servidor, hay un archivo con
un nombre “bien conocido” (etc/export) que contiene los
nombre de los sistemas de archivos locales que están
disponibles para ser “montados” remotamente.
Los Clientes utilizan una versión modificada del comando
mount al cual se le especifica el servidor y el directorio
remoto que se desea montar localmente.
La dirección (IP y puerto) del servidor y el archivo
manejado para el directorio remoto, son pasados por la
capa VFS y el cliente NFS.
Ver figura 9
CI-4821, sep-dic 2005
Puede ser realizado de manera Hard-mounted o Softmounted
Sistemas de Archivos Distribuidos
Figura 9. Acceso local y remoto al sistema de archivos en un cliente NFS
3. Sun File
System
Ser ver 1
Client
Ser ver 2
( root)
( root)
( root)
expor t
...
vmunix
usr
nfs
Remote
people
mount
big
jon
bob
...
Remote
students
x
staf f
user s
mount
jim ann
jane joe
Note: The file system mounted at /usr/students in the client is actually the sub-tree located at /export/people in Server 1;
the file system mounted at /usr/staff in the client is actually the sub-tree located at /nfs/users in Server 2.
CI-4821, sep-dic 2005
Sistemas de Archivos Distribuidos
3. Sun File
System
Traducción del nombre de ruta
En NFS, a diferencia de UNIX, la ruta de nombres
(pathnames) no pueden ser traducidas al servidor ya que
el nombre podría cruzar un mount point del lado del
cliente. El pathnames es entonces “parseado” y su
traducción es hecha de manera iterativa por el cliente:
Lookup operation.
La operación Lookup busca solo por una parte del
pathname en un directorio y retorna su correspondiente file
handle y file atributes
CI-4821, sep-dic 2005
Sistemas de Archivos Distribuidos
3. Sun File
System
Automounter
Fue agregado a la implementación de UNIX de NFS para
“montar” un directorio remoto dinámicamente en el
momento en que un “mount point” vacío sea referenciado
por el cliente.
Mantiene una tabla de “mount points” (pathnames) con
una referencia a uno o más servidores NFS listado. Se
comporta como un servidor NFS local del lado del cliente.
CI-4821, sep-dic 2005
Sistemas de Archivos Distribuidos
3. Sun File
System
Caching del Servidor
Usado para el desempeño adecuado del cliente y del
servidor NFS.
UNIX mantiene en memoria cache: páginas, directorios y
atributos de archivos que son leídos de disco. Esto
funciona porque todas las operaciones de read-write pasan
por un solo cache implementado en el kernel de UNIX.
NFS usa el cache del lado del servidor. Esto no implica
problemas de consistencia; sin embargo, cuando se llevan
a cabo operaciones de escritura, es necesario medidas
especiales.
CI-4821, sep-dic 2005
Sistemas de Archivos Distribuidos
3. Sun File
System
Caching del Cliente
Crea posibles diferencias en la información de los archivos
(o porción de archivos) que existen en distintos clientes
(nodos de clientes) ya que las escrituras en clientes no
resultan en actualizaciones inmediatas en los demás.
Los clientes son responsables por consultar (polling) al
servidor por la actualización de la información en cache
que ellos poseen.
Timestamp-based method : (para validación de cache )
Tc es el tiempo de la última validación de la entrada a cache.
Tm es el tiempo de la última modificación del bloque en el servidor.
t intervalo de refrescamiento.
(T – Tc < t) v (Tmcliente = Tmservidor)
CI-4821, sep-dic 2005
Sistemas de Archivos Distribuidos
3. Sun File
System
Otras optimizaciones
NFS está basado en UNIX BSD Fast File System que
utiliza bloques de disco de 8kb y que genera menos
llamadas al sistema de archivo para acceso secuencial de
archivos, que el sistema UNIX anterior.
Los paquetes UDP usados para la implementación de Sun
RPC se extiende a bloques de 9kb. En la versión 3 de
NFS, se negocian tamaños de bloque mayores a 8 kb,
entre clientes y servidores.
CI-4821, sep-dic 2005
Sistemas de Archivos Distribuidos
3. Sun File
System
Desempeño
Áreas problemáticas, según Sandberg:
1.El uso frecuente de las llamadas a getattr
para obtener timestamp para el servidor en las
validaciones de cache.
2.Pobre desempeño de las operaciones de
escritura por que está se realiza a través del servidor
(bottleneck).
CI-4821, sep-dic 2005
Sistemas de Archivos Distribuidos
3. Sun File
System
Conclusión
Su diseño provee buen direccionamiento y transparencia
en el acceso.
Soporta heterogeneidad.
Es sin estados, haciendo que cliente y servidor reactiven la
ejecución luego de una falla sin un procedimiento de
recuperación.
No soporta migración de archivos o sistemas de archivos
(sólo manual).
Se aleja un poco de la semántica de sólo una copia de
UNIX con el desempeño de los bloques de cache en el
cliente.
CI-4821, sep-dic 2005
Sistemas de Archivos Distribuidos
3. Sun File
System
Transparencia en el acceso: El módulo del cliente NFS
provee una interfaz de programación de aplicaciones,
idéntica al sistema de operación local ( UNIX ). Por lo tanto
es total.
Transparencia de localidad: No es forzado mas con una
buena configuración es posible hacerlo.
Transparencia de movilidad: No es lograda totalmente ya
que los clientes tienen que actualizar individualmente sus
puntos de montaje
Escalabilidad: Puede manejar cargas muy grandes, con
bastante eficiencia.
CI-4821, sep-dic 2005
Sistemas de Archivos Distribuidos
3. Sun File
System
Replicación de Archivos: Solo los archivos de lectura
pueden ser replicados
Heterogeneidad de SO: Ha sido implementado en casi
todos los SO
Tolerancia a Fallas: Al ser sin estados, son observados
como errores del sistema local
Consistencia : Se aproxima a la semántica de una sola
copia de UNIX.
Seguridad : Con uso de Kerberos.
Eficiencia : Ya ha sido probado en el mundo real lo
eficiente que puede llegar a ser bajo cargas pesadas
CI-4821, sep-dic 2005
Sistemas de Archivos Distribuidos
4. The Andrew
File System
Al igual que NFS, AFS provee acceso a archivos
compartidos de manera remota. El acceso a AFS es por la
vía normal de las primitivas de archivos de UNIX (sin
modificaciones ni recompilaciones).
Se diferencia de NFS, principalmente por su diseño e
implementación. La escalabilidad es el elemento meta de
diseño más importante: caching completo de todos los
archivos en los nodos del cliente. Se desempeña muy bien
con altos números de usuarios activos.
Características:
Whole-file serving: el contenido completo de los
archivos y directorios son transmitidos al cliente: en cache.
CI-4821, sep-dic 2005
Whole-file caching: una vez que se pasa
información al cliente es colocada en cache en el disco local:
permanentemente – peticiones abiertas sobre copias
remotas.
Sistemas de Archivos Distribuidos
4. The Andrew
File System
Escenario
•Cuando un proceso de usuario en el cliente hace una llamada
a sistema – abierta – (de un archivo en el espacio compartido)
y no es una copia en el cache local, se ubica el servidor que
posee el archivo y se le solicita.
•La copia es almacenada en el UFS local del cliente. La copia
es abierta y el file descriptor resultante de UNIX vuelve al
cliente.
•Operaciones read-write y otras sobre el archivo, por proceso,
son aplicadas a la copia local.
CI-4821, sep-dic 2005
•Cuando el proceso en el cliente hace una llamada a sistema,
si la copia local ha sido actualizada su contenido es enviado al
servidor. El servidor actualiza el contenido del archivo y el
timestamps. La copia en el disco local del cliente se conserva
en caso de ser necesitada por procesos a nivel de usuario en
el mismo grupo.
Sistemas de Archivos Distribuidos
4. The Andrew
File System
Observaciones
• Las copias locales en cache probablemente son válidas
por largo períodos.
• Este cache local puede ser ubicado en una proporción
substanciosa del espacio en disco.
• La estrategia de diseño se basa en ciertas asunciones:
•Los archivos son pequeños
•Operaciones de read over write
•Acceso secuencial
•Usuario común
•Los archivos son referenciados drásticamente. LRU
• No contempla las complicaciones de las bases de datos.
CI-4821, sep-dic 2005
Sistemas de Archivos Distribuidos
4. The Andrew
File System
Implementación
¿Cómo AFS controla cuando una llamada – abierta o
cerrada – al sistema, referente a un archivo en el área
compartida, es solicitada por un cliente?
¿Cómo el servidor mantiene el archivo requerido?
¿Cómo AFS se asegura de que las copias en cache (de
archivos) son actuales cuando estos son actualizados por
varios clientes?
CI-4821, sep-dic 2005
Sistemas de Archivos Distribuidos
Figura 10. Distribución de los procesos en el Andrew File System
Wor kstations
Ser ver s
User Venus
program
Vice
UNIX ker nel
UNIX ker nel
Venus
User
program
Netw or k
UNIX ker nel
Vice
Venus
User
program
UNIX ker nel
CI-4821, sep-dic 2005
UNIX ker nel
Sistemas de Archivos Distribuidos
Figura 11. Espacio de nombres de archivos visto por el cliente de AFS
Local
Shared
/ (r oot)
tmp
bin
. . .
vmunix
cmu
bin
Symbolic
links
CI-4821, sep-dic 2005
Sistemas de Archivos Distribuidos
Figura 12. Intercepción de la llamada al sistema en AFS
Wor kstation
User
program
Venus
UNIX f ile
system calls
Non- local f ile
oper ations
UNIX ker nel
UNIX f ile system
Local
disk
CI-4821, sep-dic 2005
Sistemas de Archivos Distribuidos
Figura 13. Implementación de las llamadas del sistema de archivos en AFS
Us er pr oces s
open(FileNam e,
mo de)
UNIX ker nel
If FileName refers to a
file in s hared file sp ace,
pass the reques t to
Venu s.
Op en th e local file and
return the file
descrip tor to the
applicatio n.
CI-4821, sep-dic 2005
r ead( FileDescriptor ,
Buffer , length)
P erfo rm a no rmal
UN IX read operation
on th e local copy .
write(FileD es cr iptor,
Buffer , length)
P erfo rm a no rmal
UN IX write operation
on th e local copy .
clo se(FileD es cr iptor)
Close the local copy
and notify Venus that
the file has been clos ed.
Venu s
Check lis t offiles in
local cache. Ifn ot
present or there is no
valid callb ack pr omis e ,
s end a request for the
file to the Vice server
that is cus to dian ofthe
volume co ntaining th e
file.
P lace th e copy ofthe
file in the local file
s ystem, en ter its local
name in th e local cache
list and return the local
name to UNIX.
Ifthe local copy has
been changed, s end a
copy to th e Vice s erver
that is the custod ian o f
the file.
Ne t
Vice
Transfer a co py of the
file and a callb ack
pr omis e to th e
wo rk station . Log the
callback p ro mis e.
Replace the file
contents and s end a
callb ack to all other
clients holding ca llba ck
pr omis es on the file.
Sistemas de Archivos Distribuidos
Figura 13. Implementación de las llamadas del sistema de archivos en AFS
Us er pr oces s
open(FileNam e,
mo de)
UNIX ker nel
If FileName refers to a
file in s hared file sp ace,
pass the reques t to
Venu s.
Op en th e local file and
return the file
descrip tor to the
applicatio n.
r ead( FileDescriptor ,
Buffer , length)
P erfo rm a no rmal
UN IX read operation
on th e local copy .
write(FileD es cr iptor,
Buffer , length)
P erfo rm a no rmal
UN IX write operation
on th e local copy .
clo se(FileD es cr iptor)
Close the local copy
Venu s
Check lis t offiles in
local cache. Ifn ot
present or there is no
valid callb ack pr omis e ,
s end a request for the
file to the Vice server
that is cus to dian ofthe
volume co ntaining th e
file.
P lace th e copy ofthe
file in the local file
s ystem, en ter its local
name in th e local cache
list and return the local
name to UNIX.
Ne t
Vice
Transfer a co py of the
file and a callb ack
pr omis e to th e
wo rk station . Log the
callback p ro mis e.
Us er pr oces s
UNIX ker nel
Venu s
Ne t
Vice
open(FileNam e,
mo de)
Sistemas de
If FileName refers to a
file in s hared file sp ace,
Check lis t offiles in
Archivospass
Distribuidos
the reques t to
local cache. Ifn ot
VenuFigura
s.
13. Implementación
dethere
las is
llamadas
del sistema de archivos en AFS
present or
no
valid callb ack pr omis e ,
s end a request for the
file to the Vice server
that is cus to dian ofthe
Transfer a co py of the
volume co ntaining th e
file.
file and a callb ack
pr omis e to th e
wo rk station . Log the
P lace th e copy ofthe
callback p ro mis e.
file in the local file
s ystem, en ter its local
Op en th e local file and
name in th e local cache
return the file
list and return the local
descrip tor to the
applicatio n.
name to UNIX.
r ead( FileDescriptor ,
Buffer , length)
P erfo rm a no rmal
UN IX read operation
on th e local copy .
write(FileD es cr iptor,
Buffer , length)
P erfo rm a no rmal
UN IX write operation
on th e local copy .
clo se(FileD es cr iptor)
Close the local copy
and notify Venus that
the file has been clos ed.
Ifthe local copy has
been changed, s end a
copy to th e Vice s erver
that is the custod ian o f
the file.
Replace the file
contents and s end a
callb ack to all other
clients holding ca llba ck
pr omis es on the file.
Sistemas de Archivos Distribuidos
Figura 13. Componentes principales del Vice Service Interface
Fetch(fid) -> attr, data
Create() -> fid
Returns the attributes (status) and, optionally, the contents of file
identified by the fid and records a callback promise on it.
Updates the attributes and (optionally) the contents of a specified
file.
Creates a new file and records a callback promise on it.
Remove(fid)
Deletes the specified file.
SetLock(fid, mode)
Sets a lock on the specified file or directory. The mode of the
lock may be shared or exclusive. Locks that are not removed
expire after 30 minutes.
Unlocks the specified file or directory.
Store(fid, attr, data)
ReleaseLock(fid)
RemoveCallback(fid)
BreakCallback(fid)
CI-4821, sep-dic 2005
Informs server that a Venus process has flushed a file from its
cache.
This call is made by a Vice server to a Venus process. It cancels
the callback promise on the relevant file.
Sistemas de Archivos Distribuidos
4. The Andrew
File System
Otros Aspectos
Modificaciones al kernel de UNIX
Operaciones en terminos de archivo, no de file descriptor
Base de Datos de Direccionamiento
Copia completa de la ubicación de archivo en el servidor
Threads
Las tablas de contenido se mantienen en cache
compartido en Venus
Cache parcial de Archivos
Mantiene la consistencia en la semántica del protocolo
AFS
CI-4821, sep-dic 2005
Sistemas de Archivos Distribuidos
4. The Andrew
File System
Desempeño
Su principal característica es la escalabilidad. Guardar en
cache todo el archivo y el protocolo de callback reducen
dramáticamente la carga en el servidor (hasta 60%,
Satyanarayanan).
El descenso se le atribuye al uso de callbacks para
notificar a los clientes por actualizaciones, en contra del
mecanismo de timeout que usa NFS para verificar la
validez de las páginas en cache de los clientes.
Wide-area support.
CI-4821, sep-dic 2005
Sistemas de Archivos Distribuidos
5. Conclusiones
:: Mejoras
1. NFS
2. AFS
3. xFS
CI-4821, sep-dic 2005
• Spritely NFS
• NQNFS
• WebNFS
• NFS 4
Sistemas de Archivos Distribuidos
5. Conclusiones
:: Mejoras
1. NFS
2. AFS
3. xFS
CI-4821, sep-dic 2005
• DFS
•Mezcla de Spritely NFS y NQNFS.
Sistemas de Archivos Distribuidos
5. Conclusiones
:: Mejoras
1. NFS
2. AFS
3. xFS
Motivacion:
• Redes de Alta Velocidad como ATM y Gigabit
Ethernet.
• Alta demanda de accesos a archivos distribuidos.
• Limitaciones de los sistemas centralizados.
xFS:
• Sistema de Archivos Distribuido.
• Implementa RAID.
• La responsabilidad de manejar un archivo la puede
tener cualquiera de los servidores de xFS.
• Rendimiento hasta 10 veces mejor que NFS y AFS
CI-4821, sep-dic 2005
Descargar

Sistemas de Archivos Distribuidos