Tema 4: Sistemas Operativos Distribuidos

Transcripción

1 Tema 4: Sistemas Operativos Distribuidos Sistemas de Ficheros Enrique Soriano LS, GSYC 15 de octubre de 2015

2 (cc) 2015 Grupo de Sistemas y Comunicaciones. Algunos derechos reservados. Este trabajo se entrega bajo la licencia Creative Commons Reconocimiento - NoComercial - SinObraDerivada (by-nc-nd). Para obtener la licencia completa, véase También puede solicitarse a Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA. Las imágenes de terceros conservan su propia licencia.

3 Sistemas de ficheros locales

4 Ficheros Tradicionalmente: datos que persisten tras la ejecución del proceso y/o del sistema (excepción: ramfs), y que son compartidos por distintos procesos y/o sistemas. Requisitos: Gran tamaño Durabilidad Acceso concurrente Protección Más general: es una interfaz. P. ej. puede representar un dispositivo.

5 Ficheros de datos Estructura: fichero simple (UNIX), Resource Forks (Mac)... Nombre: extensión? Tipos?

6 Ficheros: Estructura Interna Bloque físico determinado por el HW (sector). Tradicionalmente de 512 bytes, algunos fabricantes están pasando a 4 Kb. Bloque lógico determinado por el sistema de ficheros. Si no coinciden, empaquetamos. Siempre hay fragmentación interna en los bloques. Tamaño? compromiso entre: tamaño de bloque fragmentación tamaño de bloque tasa de transferencia

7 Discos Acceso al disco: Secuencial: se accede registro a registro (contiguos). Aleatorio: se accede a cualquier registro inmediatamente. Y los discos duros actuales? Caches flash, discos SSD, híbridos, etc.

8 Discos Direccionamiento de bloques: CHS, LBA. Así eran: 9/17/12 upload.wikimedia.org/wikipedia/commons/0/02/cylinder_head_sector.svg Track/ Cylinder Sector Heads 8 Heads, 4 Platters Imagen: Public Domain, Wikipedia

9 Discos Algoritmo de planificación de disco: cómo organiza el SO las operaciones de entrada/salida. El algoritmo depende totalmente del tipo de disco que usemos. Los clásicos: FIFO: es justo, no altera el orden de las operaciones. Lento en discos mecánicos. Shortests Seek First: no es justo, puede provocar hambruna, desordena operaciones. SCAN (Ascensor): compromiso justicia/eficiencia, no provoca hambruna, desordena operaciones.

10 Discos: RAID RAID: Redundant Array of Inexpensibe Disks. Es un caso de virtualización de almacenamiento. Pueden estar implementados por HW o por el SO.

11 Discos: RAID 0 Striping (interleaving) por bloques. Sin redundancia. Bloques contiguos se escriben en paralelo. 9/17/12 upload.wikimedia.org/wikipedia/commons/9/9b/raid_0.svg RAID 0 A1 A3 A5 A7 A2 A4 A6 A8 Disk 0 Disk 1 Imagen: (cc) from Wikipedia

12 Discos: RAID 1 Mirror. Distintas lecturas en paralelo. 9/17/12 upload.wikimedia.org/wikipedia/commons/b/b7/raid_1.svg RAID 1 A1 A2 A3 A4 A1 A2 A3 A4 Disk 0 Disk 1 Imagen: (cc) from Wikipedia

13 Discos: RAID 4 Striping (interleaving) por bloques. Dedica un disco entero para la paridad. Se soporta el fallo de un disco. 9/17/12 upload.wikimedia.org/wikipedia/commons/a/ad/raid_4.svg RAID 4 A1 B1 C1 D1 A2 B2 C2 D2 A3 B3 C3 D3 Ap Bp Cp Dp Disk 0 Disk 1 Disk 2 Disk 3 Imagen: (cc) Wikipedia

14 Discos: RAID 5 Striping (interleaving) por bloques. La paridad está distribuida por los discos. Se soporta el fallo de un disco. 9/17/12 File:RAID 5.svg - Wikipedia, the free encyclopedia Soluciona File:RAID el cuello 5.svg de botella de RAID 4. From Wikipedia, the free encyclopedia No higher resolution available. RAID_5.svg (SVG file, nominally pixels, file size: 26 KB) Imagen: (cc) Wikipedia

15 SAN SAN (Storage Area Network): proporciona almacenamiento de bloques a través de la red. Es un disco en red, no es un sistema de ficheros en red. Ejemplos: iscsi, ATA over Ethernet (AoE), HyperSCSI.

16 Particiones PC (BIOS) Esquema tradicional de los PC (se está abandonando): MBR: Primer bloque del disco (512 bytes). Cargador primario: 440 bytes. Tabla de particiones primarias: 4 entradas de 16 bytes. Arrancable/no arrancable. Dirección del primer bloque (CHS). Tipo de partición (ntfs, linux, linux swap, plan9,...). Dirección del último bloque (CHS). Dirección del primer bloque (LBA). Número de bloques de la partición. Direcciones de 32 bits: como mucho discos de 2TB.

17 Particiones UEFI GUID Partition Table (GPT) : Usa direcciones y tamaños de 64 bits. Primer bloque (LBA 0): legacy MBR. Segundo bloque (LBA 1): GPT header, con punteros para: Array de bloques con la tabla de particiones (empieza en LBA 2). El array tiene un tamaño mínimo de 16 Kb independientemente del tamaño del sector físico. Las entradas en la tabla (128 bytes) continenen: tipo de particion, LBA del primer bloque, LBA del último bloque, atributos (read-only, oculta, etc.), nombre de particion... Copia de la cabecera. El primer bloque usable.... El cargador está en una partición de tipo ESP (EFI System Partition, que es una FAT).

18 Volúmenes Lógicos Los volúmenes lógicos (LV) pueden estar formados por distintos trozos (physical extends, PE) de distintos volúmenes físicos (PV). P. Ej. Linux LVM.

19 Sistemas de Ficheros Invención del SO para ofrecernos ficheros. Se puede implementar de distintas formas: asignación continua, enlazada, enlazada con tabla, indexada...

20 Asignación de espacio (FS): contigua Un fichero ocupa una serie de bloques contiguos en disco. Acceso rápido en discos de acceso secuencial. Rendimiento alto: un acceso para conseguir un dato cualquiera la entrada de directorio contiene la dirección de inicio y la longitud del fichero. Problema: si hay asignación dinámica fragmentación externa. Problema: hay que saber el tamaño máximo del fichero cuando se crea. Tamaños limitados por los huecos compactación.

21 Asignación de espacio (FS): enlazada Un fichero es una lista enlazada de bloques. Se tienen punteros al primer y al último bloque. Datos por bloque = tamaño de bloque - tamaño de estructura. Ventajas: No hay fragmentación externa. Tamaños no limitados por huecos. Problemas: Acceso aleatorio ineficaz. Necesitamos estructura de metadatos en cada bloque para el enlace. qué pasa si se pierde una estructura?

22 Asignación de espacio (FS): enlazada de clusters Cluster: agrupación de bloques contiguos (e.g. 32 Kb). No se desperdicia tanto (1 estructura para n bloques). Búsqueda más rápida (menos saltos). Aumenta la fragmentación interna.

23 Asignación de espacio (FS): enlazada con tabla Tabla FAT: La tabla FAT reside en memoria. Una entrada por cluster. El índice de la tabla es el número de cluster. La entrada de directorio tiene la referencia a la entrada primer cluster. La entrada del cluster actual referencia la entrada del siguiente cluster. Mejora del acceso aleatorio: no hay que leer los clusters del fichero para conseguir la dirección del cluster N.

24 Asignación de espacio (FS): enlazada con tabla n FAT MYFILE.txt First: 4 clusters:

25 Asignación enlazada con tabla: FAT Tabla FAT en memoria principal no puede ser muy grande clusters grandes fragmentación interna. El acceso aleatorio es más rápido que en lista enlazada normal. Y si se estropea la tabla FAT?

26 Ejemplo: FAT32 Reserved sectors Fat Region Data Region El sector 0 de la partición es el boot sector (también está duplicado en el sector 6). Contiene código del cargador secundario e información sobre el sistema de ficheros: N o de sectores, 4 bytes (Max. tam. de disco: 2 Tb) Etiqueta del volumen. N o de copias de la tabla FAT. Primer cluster del raíz....

27 Ejemplo: FAT32 Entrada de directorio (32 bytes): Nombre del archivo, 8 Bytes. Extensión del archivo, 3 Bytes. Atributos del archivo, 1 Byte. Reservado, 10 Bytes. Hora de la última modificación, 2 bytes. Fecha de la última modificación, 2 bytes. Primer cluster del archivo, 4 bytes. Tamaño del archivo, 4 bytes. Clusters de 32 Kb, 64 sectores.

28 Asignación de espacio (FS): indexada Idea: se indexan los bloques de datos del fichero en un bloque de indirección. Bloque de indirección grande desperdicio. Bloque de indirección pequeño no soporta ficheros grandes. Para un acceso a datos, siempre son dos accesos a disco.

29 Asignación de espacio (FS): indexada multinivel Por niveles. P. ej. indirección doble: Los bloques de índice de 1er nivel apuntan a bloques de índice de 2 o nivel. Los bloques de índice de 2 o nivel apuntan a bloques de datos. Ejemplo: bloques de 4Kb con punteros de 4 bytes. Problema: Para los ficheros pequeños, desperdiciamos. Problema: Para un acceso a datos, n accesos a disco.

30 Asignación de espacio: indexada con esquema combinado Algunos bloques directos de datos. Algunos bloques de indirección simple. Algunos bloques de indirección doble.... Nos quedamos con lo mejor de cada modelo anterior.

31 Ficheros en UNIX: I-NODOS Asignación indexada con esquema combinado: I-NODE Data Metadata (size, mode, etc.) Data... Data Direct Blocks Data Data Single Indirect Direct Blocks... Data Data Double Indirect... Data Triple Indirect Single Indirect Direct Blocks... Data

32 UNIX: Partición Boot Block Super Block I-Node vector Data Bloque de arranque (boot block): código de arranque del sistema. Superbloque: tamaño del volumen, número de bloques libres, lista de bloques libres, tamaño del vector de i-nodos, siguiente i-nodo libre, cierres... Vector de i-nodos: representación de los ficheros. Bloques de datos.

33 UNIX: I-NODOS Cada fichero/directorio tiene un i-nodo asociado, definido por un número de i-nodo. El directorio raíz siempre tiene el número de i-nodo 2. La estructura se localiza en el vector indexando por el número de i-nodo. El OS mantiene una cache de i-nodos en memoria.

34 UNIX: I-NODOS La estructura contiene: permisos tiempos acceso a datos (atime) modificación de los datos (mtime) modificación del i-nodo (ctime) tamaño dueño tipo número de bloques contador de referencias (links) No contiene el nombre de fichero.

35 UNIX: I-NODOS Un directorio relaciona un nombre con un i-nodo, en una entrada (dentry). Un directorio tiene: Su propio i-nodo Bloques de datos con la lista de entradas Entre las entradas, tiene la entrada de. (su i-nodo) y.. (i-nodo del padre). El OS también mantiene una cache de entradas de directorio en memoria.

36 UNIX: I-NODOS /home/joe/test.txt ROOT usr 5 home... I-NODE 5 DATA BLOCK joe jane... I-NODE 7 DATA BLOCK test.txt... METADATA direct-block 321 METADATA direct-block 239

37 UNIX: I-NODOS Enlaces duros: es otro nombre para el fichero, la entrada de directorio apunta al mismo i-nodo que el antiguo nombre. Enlaces simbólicos: es un fichero cuyos datos contienen la ruta al fichero enlazado pueden romperse.

38 Implementación de directorios Lineal Pro: simple. Contra: búsqueda lineal. Lineal ordenada Pro: búsqueda binaria. Contra: complica creación y borrado. Tabla hash con desbordamiento Pro: mucho más rápida que lineal. Contra: más complejidad. Árboles (e.g. b+ en NTFS, JFS...)...

39 Gestión de espacio libre Bitmap: rápido. Inconveniente: puede ser demasiado grande como para tenerlo entero en memoria.p. ej. para 2TB de bloques mapa de 512 MB. Lista enlazada de bloques libres: ineficiente si buscamos varios, pero por lo general sólo se busca uno libre. Agrupaciones: el primer nodo en la lista no está vacío; tiene enlaces a n bloques libres, los n-1 primeros vacíos, el último con n más. Ventaja: se pueden encontrar rápidamente las direcciones de n bloques libres. Cuenta: guarda en una lista el bloque libre y el número de bloques contiguos libres que le siguen.

40 Espacio de nombres Se camina (walk) por la ruta, resolviendo cada parte. Se pueden pegar árboles a nuestro espacio de nombres: mount. Unix: un espacio de nombres para el sistema (comando mount para listarlo). Plan 9: es controlable, puede haber un espacio de nombres por proceso (comando ns para listarlo). Linux y otros han adoptado esta idea.

41 Espacio de nombres % 9fs marmita / usr bin n marmita PUNTO DE MONTAJE FICHERO MONTADO / 386 usr bin...

42 Imágenes de disco Un fichero que tiene dentro la estructura completa (sector por sector) de un disco duro, CD-ROM (ISO 9660), floppy, etc. Utilidad: clonar sistemas, backups, crear CD/DVD, descargar discos, máquinas virtuales, etc.

43 Imágenes de disco Ejemplo en Linux: crear y usar una imagen de floppy: ~$ # creo un fichero de 1,44 MB con ceros ~$ dd if=/dev/zero of=/tmp/f bs=512 count=2880 ~$ # formateo la imagen de floppy con VFAT ~$ mkfs.vfat -v -c /tmp/f ~$ # monto en el punto de montaje /mnt/floppy ~$ mount -o loop /tmp/f -t vfat /mnt/floppy ~$ # creo un fichero en el floppy ~$ touch /mnt/floppy/afile ~$ # ver el espacio de nombres ~$ mount ~$ # desmontar el volumen ~$ umount /mnt/floppy

44 Uniones Consiste en unir varios directorios en uno. Utilidades: compartir código fuente, agrupar binarios (/bin), reunir ficheros para crear un backup (CD,DVD,...), distribuciones live, etc. Idea de Plan 9. UnionFS y Aufs en UNIX.

45 Uniones Ejemplo en Plan 9: crear una unión de tres directorios en el directorio $home/union term % bind -bc /tmp/a $home/union term % bind -bc /tmp/b $home/union term % # en $home/union vemos los ficheros de term % # /tmp/b, /tmp/a, y $/home/union, en ese orden term % ls $home/union

46 Mecanismo: Proyección en memoria mmap: mapea un fichero en memoria para poder acceder a los datos del fichero como si fuese un buffer, sin usar read ni write. El fichero se trae poco a poco paginación por demanda. Llamadas al sistema: mmap y munmap en UNIX.

47 Sistemas de ficheros con historico (snapshots) Venti es un servidor de bloques en espacio de usuario, identificados por su hash SHA-1 (20 bytes). Venti nunca borra los bloques. Fossil es un sistema de ficheros en espacio de usuario, que puede usar bloques del disco y bloques de venti. Fossil tiene snapshots efímeros y permanentes. Para crear un snapshot permanente, archiva los bloques en venti.

48 FS en espacio de usuario En algunos sistemas, es lo normal (P. ej. Plan 9). En UNIX: VFS (Virtual File System): interfaz común con el kernel para todos los FS. FUSE: módulo del kernel para implementar sistemas de ficheros en espacio de usuario que se puedan integrar con VFS.

49 FS en espacio de usuario en UNIX Userspace App App App FS Kernel VFS FUSE UFS EXT3 VFAT

50 Cache El kernel mantiene una cache en RAM para los bloques. Es muy eficiente. P. ej. La buffer cache de 4.4BSD evita el 85 % de los accesos a disco/red para conseguir bloques. En ocasiones es recomendable saltársela (e.g. modo O DIRECT de open en Linux). Cuando el sistema se está quedando sin marcos de página, se suele sacrificar espacio de la cache. El comando y llamada al sistema sync de UNIX sincroniza la cache con el disco y actualiza el superbloque. Se ejecuta periódicamente.

51 Cache Tipos de cache (en general): Escrituras: Síncrona (write-through): evita problemas de coherencia. Asíncrona (delayed write-back): incrementa el rendimiento. Para accesos secuenciales: Read-ahead. Free-behind.

52 Fallos Perder la integridad de los metadatos (estructuras del FS) es peor que perder datos. Usamos una cache write-back para los datos y/o los metadatos? Al crear un fichero, creamos antes el i-nodo o la entrada en el directorio? Al borrar un fichero, liberamos antes el i-nodo o su entrada en el directorio?

53 Fallos Después de un fallo: Hay programas para reparar el sistema de ficheros, e.g. fsck en UNIX. Hay que recorrer los bloques de los ficheros para detectar errores, e.g.: Un bloque está asignado a un fichero y en la lista de bloques libres a la vez. Un bloque en dos ficheros a la vez. Esto es caro.

54 Journaling Ideas básicas: Las operaciones se escriben en un journal (en disco) de forma atómica. Una vez escritas en el journal las operaciones están comprometidas. En algún momento las operaciones se aplicarán en el FS. Si el sistema falla, al rearrancar se aplican todas las operaciones pendientes en el journal (si las hay) para recuperar la coherencia. Desventaja: hay que escribir los datos dos veces en el disco (pero en el journal es secuencial). Normalmente se hace journaling sólo de los metadatos.

55 Soft Updates Ideas básicas: La escritura de los metadatos es asíncrona (write-back). El usuario siempre ve la versión más reciente (en cache). En el disco siempre hay una versión coherente. Se establecen dependencias entre las escrituras de metadatos, que marcan el orden al que van al disco, e.g.: Nunca se referencia una estructura no inicializada. Nunca se reusa una estructura sin borrar todas las referencias a la misma. No se borra un puntero antiguo hasta que el nuevo está puesto (e.g. renombrado de un fichero). Tras un fallo, se puede montar el volumen inmediatamente. Es complicado de implementar, mantener y ampliar.

56 Soft Updates Ejemplo de situación de rollback, dependencia cíclica: Las entradas de directorio de /A/B y de /A/C están en el mismo bloque X. Los inodos de /A/B y de /A/C están en el mismo bloque Y. Se quieren hacer las siguientes operaciones: 1. Crear fichero /A/B, pasos: 1.1 Actualizar i-nodo (modifica Y) 1.2 Meter entrada de directorio (modifica X) 2. Borrar fichero /A/C, pasos: 2.1 Borrar entrada de directorio (modifica X) 2.2 Marcar i-nodo como libre (modifica Y) No se puede escribir en disco el bloque Y antes que el bloque X, ni viceversa. Hay que deshacer una operación, escribir los bloques, rehacerla, y escribir de nuevo los bloques.

57 Sistemas de ficheros distribuidos

58 Sistemas de ficheros en red Permite compartir ficheros a través de la red siguiendo un esquema cliente/servidor. El cliente y el servidor deben hablar un protocolo de sistema de ficheros. Protocolos: NFS, CIFS/SMB, WebDAV, 9P, AFP,... NAS (Network-Attached Storage): HW especializado en servir un FS en red, con RAID, etc.

59 Sistemas de ficheros en red Stateless Sencillo. Operaciones autocontenidas. Los handles que da el servidor tienen que ser únicos (eg. fs id + inodo + versión). No requiere recuperación tras un fallo. El servidor se puede reemplazar. Stateful Sesiones / estado permanente. El servidor puede olvidar los handles después de una sesión. Fallo del servidor recuperar del estado o abortar. Cache coherente? Locking/ Leases? Callbacks? Read-ahead? DMEXCL?

60 Semánticas de compartición de ficheros Las más comunes: Semántica UNIX (Strong Consistency). Semántica de sesión. Ficheros inmutables. Transacciones. Coherencia débil (Weak Consistency): ventana de coherencia.

61 NFS Varias versiones diferentes. Hasta NFSv3 era stateless: File handles opacos, elegidos por el servidor. No hay open ni close. Problemas con locking, coherencia de cache, etc. NFSv4: stateful, RPCs compuestas, etc. Muy complejo: ACCESS, BACKCHANNEL CTL, BIND CONN TO SESSION, CLOSE, COMMIT, CREATE, CREATE SESSION, DELEGPURGE, DELEGRETURN, DESTROY CLIENTID, DESTROY SESSION, EXCHANGE ID, FREE STATEID, GETATTR, GETDEVICEINFO, GETDEVICELIST, GETFH, GET DIR DELEGATION, LAYOUTCOMMIT, LAYOUTGET, LAYOUTRETURN, LINK, LOCK, LOCKT, LOCKU, LOOKUP, LOOKUPP, NVERIFY, OPEN, OPENATTR, OPEN CONFIRM, OPEN DOWNGRADE, PUTFH, PUTPUBFH, PUTROOTFH, READ, READDIR, READLINK, RECLAIM COMPLETE, RELEASE LOCKOWNER, REMOVE, RENAME, RENEW, RESTOREFH, SAVEFH, SECINFO, SECINFO NO NAME, SEQUENCE, SETATTR, SET CLIENTID, SET CLIENTID CONFIRM, SET SSV, TEST STATEID, VERIFY, WANT DELEGATION, WRITE...

62 UNIX + NFS Client Userspace File Server Userspace App App App App App App system calls Kernel system calls Kernel VFS VFS UFS EXT3 VFAT NFS client UFS NFS server NFS RPC network

63 9P Stateful: el servidor mantiene el estado de la conexión. Stateful: posibilita la exportación de ficheros sintéticos. Sencillo: sólo 13 RPCs. Totalmente integrado con el SO: el kernel de Plan 9 es un multiplexor de 9P.

64 9P Userspace Userspace FS FS App FS system calls 9P 9P 9P* 9P* 9P* Kernel Kernel #M mount driver... #p proc... #c cons FS 9P network 9P 9P 9P*: Within the kernel, 9P is implemented by procedure calls to the various kernel device drivers.

65 9P: RPCs size[4] Tversion tag[2] msize[4] version[s] size[4] Rversion tag[2] msize[4] version[s] Acuerda la versión del protocolo y comienza una nueva sesión. size[4] Tauth tag[2] afid[4] uname[s] aname[s] size[4] Rauth tag[2] aqid[13] Autenticación (externa a través de P9SK1). size[4] Rerror tag[2] ename[s] Error para todos los tipos de peticiones. size[4] Tflush tag[2] oldtag[2] size[4] Rflush tag[2] Aborta la petición identificada con oldtag.

66 9P: RPCs size[4] Tattach tag[2] fid[4] afid[4] uname[s] aname[s] size[4] Rattach tag[2] qid[13] El cliente se ata al raíz del sistema de ficheros. A partir de este momento se referirá a él con el FID. El servidor responde con un identificador único para el raíz QID (versión, tipo y path). size[4] Twalk tag[2] fid[4] newfid[4] nwname[2] nwname*(wname[s]) size[4] Rwalk tag[2] nwqid[2] nwqid*(wqid[13]) Resuelve un path, que será referido con el FID newfid. Si no se pueden atravesar todos los nombres, newfid será fid. El servidor devuelve la lista de QIDs de los nombres que se han podido atravesar.

67 9P: RPCs size[4] Topen tag[2] fid[4] mode[1] size[4] Ropen tag[2] qid[13] iounit[4] size[4] Tcreate tag[2] fid[4] name[s] perm[4] mode[1] size[4] Rcreate tag[2] qid[13] iounit[4] size[4] Tread tag[2] fid[4] offset[8] count[4] size[4] Rread tag[2] count[4] data[count] size[4] Twrite tag[2] fid[4] offset[8] count[4] data[count] size[4] Rwrite tag[2] count[4]

68 9P: RPCs size[4] Tremove tag[2] fid[4] size[4] Rremove tag[2] size[4] Tstat tag[2] fid[4] size[4] Rstat tag[2] stat[n] size[4] Twstat tag[2] fid[4] stat[n] size[4] Rwstat tag[2] size[4] Tclunk tag[2] fid[4] size[4] Rclunk tag[2] Cierra el fichero representado por ese FID, ya no será referido más.

69 9P: RPCs Figure 1: Styx dialog between a client (left) and a server (rigth). anewfid (16 in the figure), which st of the fid mentioned (15 in the figure) this request walks that new fid to a p its original position in the server s fil case, fid 16 points to the file /a/b/c w once the walk transaction completes. a stat request asks the server for meta entry) for the file identified by the fid client issues a clunk request when it n to use a particular fid, to let the serv it and release any resource used on it The part in the figure below the l corresponds to a client reading a file request defines a new fid (16 again) a the file of interest, /a/b/c in this c open transaction opens the fid for the in the request (not shown). After rece the client issues read requests (and th with data) for the offsets and number o Usually, the series of read transaction by a last one, which is used by the s the client that there is no more data the offset requested; this is the end-of At this point, the client probably clos a clunk transaction releases (and clos

70 Otros tipos de sistemas de ficheros en red Distributed FS (réplicas distribuidas). Distributed version control systems. Cluster FS.

71 Distributed FS (réplicas) Los nodos tienen una réplica (on-disk cache) del árbol de ficheros. Finalidad: trabajar desconectado. Hay que resolver conflictos a la hora de sincronizar las réplicas. Ejemplos: CODA, AFS, etc.

72 Distributed version control systems Sistemas que sirven para mantener copias de un árbol con control de versiones. Guarda las distintas versiones de los ficheros, gestiona commits, puede crear distintas ramas, etc. Finalidad: principalmente, coordinar cambios en el código fuente de un proyecto de forma distribuida. También hay que resolver conflictos a la hora de sincronizar las réplicas. Ejemplos: Git, Mercurial, etc.

73 Cluster FS Los bloques de los ficheros están distribuidos en un cluster. Finalidad: file striping. Ejemplos: Google FS, Hadoop Distributed File System (HDFS), Microsoft Cluster Shared Volumes (CSV), etc.

74 Caso: Google FS Tolera fallos de los servidores. Optimizado para append y lecturas. Escalabilidad: miles de nodos por cluster, petabytes de datos. No muchos ficheros, pero ficheros muy grandes. Sacrifican latencia por throughput. Coherencia relajada: las réplicas pueden diferir en ciertas partes. Las aplicaciones deben lidiar con esto. Ficheros partidos en chunks de 64Mb (con checksum).

75 Caso: Google FS Imagen: (CC) Wikipedia

76 Caso: Google FS Master: Único punto de fallo? Shadow Masters. Cuello de botella? No, sólo mantiene el control, no hace I/O, ni coordina modificaciones en los chunks (mutación).

77 Caso: Google FS Master: Almacena sólo los metadatos: todo en memoria, log en disco para asegurar coherencia. Las actualizaciones de metadatos son atómicas. Controla el espacio de nombres. Hace polling para localizar los chunks, rebalancear y controlar caídas de chunk-servers. Crea nuevos chunks. Ordena la replicación de chunks en chunk-servers (3+). Controla los leases de las réplicas primarias. Controla los locks sobre ficheros/directorios. Realiza la recolección de basura. No coordina las mutaciones (un write en un chunk).

78 Caso: Google FS Cliente: No tienen cache de datos. Tiene cache (con tiempo de caducidad) de metadatos (chunk-handles, etc.). Suele resolver distintos chunks a la vez.

79 Caso: Google FS Mutación: Write (poco usada) 1. El cliente pide al Master la lista de réplicas y el primario. 2. El Master elige un primario si no hay. El primario adquiere un lease. El cliente cachea la respuesta del Master para futuras peticiones. Esos datos pueden caducar. 3. El cliente envía los datos a todas las réplicas. Las réplicas guardan los datos en sus buffers. 4. El cliente envía una petición write al primario. 5. El primario serializa las distintas mutaciones que recibe y las aplica al chunk. Va enviando la secuencia al resto de réplicas. 6. Cada réplica aplica las modificaciones en el orden que dicta el primario. Al aplicar un cambio, notifica al primario. 7. Tras recibir las notificaciones de las réplicas para el write, se responde al cliente. Si hay error en las réplicas, el cliente puede reintentar (desde el paso 3 o desde el paso 1). Después del fallo habrá zonas de la réplica fallida incoherentes semántica relajada (weak). Figure extracted from the original GFS paper (SOSP 2003).

80 Caso: Google FS Mutación: Atomic Record Append (muy usada) 1. El cliente envía los datos del append a todas las réplicas. 2. El cliente ordena el atomic-append al primario. 3. El primario comprueba si se desborda el último chunk. Si se desborda, se rellena con un hueco el chunk y se le indica al cliente que la operación se debe realizar en el siguiente chunk (el Master lo creará) Fragmentación interna. El tamaño de un append está limitado para evitar mucha fragmentación (1/4 de tamaño de chunk). Si no se desborda, se serializa la escritura en el chunk como en un write. 4. Si falla alguna réplica secundaria,se repite la operación append El offset se avanza de todas formas en las réplicas que fallaron: todos los chunks tienen el mismo tamaño). Los datos del append aparecen repetidos en las réplicas que no fallaron semántica at-least-once.

81 Bibliografía A. S. Tanenbaum. Operating Systems, design and implementaiton. Pearson Prentice Hill. A. S. Tanenbaum. Distributed Systems. Pearson Prentice Hill. A. S. Tanenbaum. Modern Operating Systems. Pearson Prentice Hill. A. Silberschatz. Operating Systems. Wiley. Plan 9 User Manual, Section 5, Introduction (man 5 0intro). S. Ghemawat, H. Gobioff, S. Leung. The Google File System. SOSP 2003.