1 / 51

Sistemas de Archivos Distribuidos

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. Introducción

felix-combs
Download Presentation

Sistemas de Archivos Distribuidos

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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

  2. Sistemas de Archivos Distribuidos Índice • Introducción • 1.1 Características de los Sistemas de Archivo. • 1.2 Requerimientos de los Sistemas de Archivos Distribuidos. • Arquitectura del Sistema de Archivos • Sun Network File System • 3.1 El Paradigma y su optimalidad. • The Andrew File System • 4.1 El Paradigma y su optimalidad. • 5. Comparación • 6. Conclusiones: Mejoras.

  3. 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

  4. Sistemas de Archivos Distribuidos Figura 1. Tipos de sistemas de almacenamiento Sharing Persis- Distributed Consistency Example tence cache/replicas maintenance Main memory 1 RAM 1 File system UNIX file system Distributed file system Sun NFS Web server Web Distributed shared memory Ivy Remote objects (RMI/ORB) CORBA 1 1 Persistent object store CORBA Persistent Object Service 2 Peer-to-peer storage system 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

  5. Sistemas de Archivos Distribuidos Figura 2. Estructura de Módulos • Introducción • 1.1. Características • de los Sistemas • de Archivo. CI-4821, sep-dic 2005

  6. filedes = open(name, mode) Opens an existing file with the given name. filedes = creat(name, mode) 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. status = close(filedes) Closes the open file filedes. count = read(filedes, buffer, n) Transfers n bytes from the file referenced by filedes to buffer. Transfers n bytes to the file referenced by filedes from buffer. count = write(filedes, buffer, n) Both operations deliver the number of bytes actually transferred and advance the read-write pointer. pos = lseek(filedes, offset, Moves the read-write pointer to offset (relative or absolute, whence) depending on whence). status = unlink(name) Removes the file name from the directory structure. If the file has no other names, it is deleted. status = link(name1, name2) Adds a new name (name2) for a file (name1). status = stat(name, buffer) Gets the file attributes for file name into buffer. Sistemas de Archivos Distribuidos Figura 3. Operaciones del sistema de Archivos de UNIX CI-4821, sep-dic 2005

  7. Sistemas de Archivos Distribuidos • Introducción • 1.1.Características • de los Sistemas • de Archivo. • 1.2. Requerimiento • de los Sistemas • de Archivos • Distribuidos. 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 CI-4821, sep-dic 2005

  8. Sistemas de Archivos Distribuidos • 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

  9. Sistemas de Archivos Distribuidos • 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

  10. Sistemas de Archivos Distribuidos • Introducción • 1.1.Características • de los Sistemas • de Archivo. • 1.2. Requerimiento • de los Sistemas • de Archivos • Distribuidos. 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. CI-4821, sep-dic 2005

  11. Client computer Server computer Directory service Application Application program program Flat file service Client module Sistemas de Archivos Distribuidos Figura 4. Arquitectura del sistema de archivos 2. Arquitectura del Sistema de Archivos CI-4821, sep-dic 2005

  12. Sistemas de Archivos Distribuidos 2. Arquitectura del Sistema de Archivos • 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. CI-4821, sep-dic 2005

  13. Read(FileId, i, n) -> Data If 1 ≤ i ≤ Length(File): Reads a sequence of up to n items — throws BadPosition from a file starting at item i and returns it in Data. Write(FileId, i, Data) If 1 ≤ i ≤ Length(File)+1: Writes a sequence of Data to a — throws BadPosition file, starting at item i, extending the file if necessary. Create() -> FileId Creates a new file of length 0 and delivers a UFID for it. Delete(FileId) Removes the file from the file store. GetAttributes(FileId) -> Attr Returns the file attributes for the file. SetAttributes(FileId, Attr) Sets the file attributes (only those attributes that are not shaded in Figure 8.3). Sistemas de Archivos Distribuidos Figura 5. Arquitectura del sistema de archivos 2. Arquitectura del Sistema de Archivos CI-4821, sep-dic 2005

  14. 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

  15. Lookup(Dir, Name) -> FileId Locates the text name in the directory and returns the — throws NotFound relevant UFID. If Name is not in the directory, throws an exception. AddName(Dir, Name, FileId) If Name is not in the directory, adds (Name, File) to the — throws NameDuplicate directory and updates the file’s attribute record. If Name is already in the directory: throws an exception. UnName(Dir, Name) If Name is in the directory: the entry containing Name is — throws NotFound removed from the directory. If Name is not in the directory: throws an exception. GetNames(Dir, Pattern) -> NameSeq Returns all the text names in the directory that match the regular expression Pattern. Sistemas de Archivos Distribuidos Figura 6. Operaciones del servicio de Directorio 2. Arquitectura del Sistema de Archivos CI-4821, sep-dic 2005

  16. 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 16bits identificador del Grupo de archivos CI-4821, sep-dic 2005

  17. 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

  18. Client computer Server computer Application Application program program UNIX system calls UNIX kernel UNIX kernel Virtual file system Virtual file system Local Remote UNIX UNIX Other file system NFS NFS file file client server system system NFS protocol Sistemas de Archivos Distribuidos Figura 7. Operaciones del servicio de Directorio CI-4821, sep-dic 2005

  19. 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

  20. 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

  21. 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 seguridadya que cualquier proceso se puede comportar como cliente. 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. CI-4821, sep-dic 2005

  22. lookup(dirfh, name) -> fh, attr Returns file handle and attributes for the file name in the directory dirfh. create(dirfh, name, attr) -> Creates a new file name in directory dirfh with attributes attr and newfh, attr 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.) Sets theattributes (mode, user id, group id, size, access time and setattr(fh, attr) -> attr 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. Sistemas de Archivos Distribuidos Figura 8. Operaciones del servidor NFS – 1 Continúa en la próxima lámina… CI-4821, sep-dic 2005

  23. symlink(newdirfh, newname, string) Creates an entry newname in the directory newdirfh of type -> status 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. Sistemas de Archivos Distribuidos Figura 8. Operaciones del servidor NFS – 2 CI-4821, sep-dic 2005

  24. 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

  25. 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 Puede ser realizado de manera Hard-mounted o Soft-mounted CI-4821, sep-dic 2005

  26. Sistemas de Archivos Distribuidos Figura 9. Acceso local y remoto al sistema de archivos en un cliente NFS 3. Sun File System 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

  27. 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

  28. 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

  29. 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

  30. 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

  31. 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

  32. 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

  33. 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

  34. 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

  35. 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

  36. 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. 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. CI-4821, sep-dic 2005

  37. 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. • 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. CI-4821, sep-dic 2005

  38. 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

  39. 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

  40. Sistemas de Archivos Distribuidos Figura 10. Distribución de los procesos en el Andrew File System CI-4821, sep-dic 2005

  41. Sistemas de Archivos Distribuidos Figura 11. Espacio de nombres de archivos visto por el cliente de AFS CI-4821, sep-dic 2005

  42. Sistemas de Archivos Distribuidos Figura 12. Intercepción de la llamada al sistema en AFS CI-4821, sep-dic 2005

  43. Sistemas de Archivos Distribuidos Figura 13. Implementación de las llamadas del sistema de archivos en AFS CI-4821, sep-dic 2005

  44. Sistemas de Archivos Distribuidos Figura 13. Implementación de las llamadas del sistema de archivos en AFS

  45. Sistemas de Archivos Distribuidos Figura 13. Implementación de las llamadas del sistema de archivos en AFS

  46. Fetch(fid) -> attr, data Returns the attributes (status) and, optionally, the contents of file identified by the fid and records a callback promise on it. Store(fid, attr, data) Updates the attributes and (optionally) the contents of a specified file. Create() -> fid 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. ReleaseLock(fid) Unlocks the specified file or directory. RemoveCallback(fid) Informs server that a Venus process has flushed a file from its cache. BreakCallback(fid) 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 Figura 13. Componentes principales del Vice Service Interface CI-4821, sep-dic 2005

  47. 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

  48. 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

  49. Sistemas de Archivos Distribuidos • Conclusiones:: Mejoras • NFS • AFS • xFS • Spritely NFS • NQNFS • WebNFS • NFS 4 CI-4821, sep-dic 2005

  50. Sistemas de Archivos Distribuidos • Conclusiones:: Mejoras • NFS • AFS • xFS • DFS • Mezcla de Spritely NFS y NQNFS. CI-4821, sep-dic 2005

More Related