DAS: Direct-attached storage disco asociado a nodo

Tolerancia a fallos SW NAS: Network-attached storage Nodo que gestiona un conjunto de discos
Plataforma basada en commodity HW
No altas prestaciones pero gran paralelismo Conexión de dispos. Red dedicada al almacenamiento Almacenamiento no vinculado a ningún nodo
almacenamiento
Modo de operación batch Redes comunicación separadas para datos de aplicación y ficheros
Perfil de aplicaciones previstas
Millones de ficheros grandes SAN: Storage Area Networks Redes de almacenamiento incluyen hubs, switches, etc.
Intro
Escritor genera fichero completo inmutable Conectividad total entre nodos y dispositivos:
Patrones de acceso típicos
Múltiples escritoresañaden Conectividad directa entre dispositivos

Con gran paralelismo

Google juega con ventaja Datos de fichero distribuidos entre discos del sistema
Por la especialización hacia el éxito Uso de stripping
Especialización: sí pero no demasiada Similar a RAID 0 pero por software y entre varios nodos

Mayoría lecturas grandes (>1MB) y secuenciales shared disk file systems Nuevo reparto de funcionalidad de SF en 2 niveles

Algunas lecturas pequeñas aleatorias Sistemas de Proporcionado por la SAN

ficheros paralelos Nivel inferior: servicio de almacenamiento distribuido
Mayoría escrituras grandes (>1MB) y secuenciales Perfil de aplicaciones Si no SAN, módulo de servicio de disco en cada nodo E/S (NES)

Habitual escrituras pequeñas simultáneas al final del fichero Cada NC accede a los discos como si fueran locales
Carga de trabajo prevista y API
Escrituras pequeñas aleatorias no previstas Nivel superior: sist. ficheros en cada nodo de cómputo (NC) Cada NC gestiona la metainfo. de los datos que accede

API, y modelo de coherencia, no estándar Se requiere un mecanismo de cerrojos distribuido

Tomar como base un SF convencional Gran escala soporte grandes volúmenes, ficheros y directorios
Sistema de ficheros para clusters
Añadir: cada trozo de fichero almacenado en nodo distinto Presente en la mayoría de los Top 500

problema de fiabilidad -> réplicas Datos repartidos en discos Soporte para SAN y nodos con discos: Shared disk file system
Receta para diseñar Una primera aproximación a GFS File System
No usar caché en nodos cliente Sistemas heterogéneos

Único nodo maestro gestiona toda la información del SF Semántica POSIX Escrituras atómicas
Intro
a del nodo maestro Escalabilidad
Sistemas de
Facilidades para implementar biblioteca MPI-IO

Trozos fichero repartidos entre nodos de almacenamiento (NA)

ficheros paralelos
Optimiza acceso para 1 fichero/N procesos y N ficheros/1 proceso
Paralelismo en gestión de datos y metadatos
Tamaño de trozo/chunk/stripe: ¡64MB Ops. administración también con paralelismo y “en caliente”

mejor aprovechamiento discos y red Clásicas Tolerancia a fallos en discos, nodos y comunicación
Ventajas Striping
Menos gasto de memoria Bloques de fichero repartidos round-robin en discos de un SF
Escalabilidad del maestro
Menos trabajo Si SF formado por RAIDs: T múltiplo de tamaño franja de RAID
Tamaño bloque T entre 16K y 1M: típico 256K
relacionadas con fragmentació Clásicas Ficheros pequeños y colas de ficheros: subbloques de hasta T/32
Desventajas
Striping
Menos paralelismo Uso de prefetching en lecturas con detección de patrones de acceso:
Lecturas y escrituras de un nodo aprovechan paralelismo
Evolución de las necesidades Uso de write-behind para escrituras paralelas en discos
Finalmente se nos ha quedado pequeño
Problemas (relación directa/indirecta con maestro único) Configuración maximizando rendimiento o prestaciones
Si discos de un SF no uniformes en tamaño y/o prestaciones
GFS entra en la era de los “múltiples maestros” Reparto de bloques no uniforme

reescritura completa Datos de los ficheros

GFS II/Colossus
Tamaño de bloque 1MB SF gestiona diversos tipos de “objetos” Metadatos del fichero inodo y bloques indirectos

Tiempo de recuperación de pocos segundos Metadatos del sistema de ficheros información de espacio libre, etc.
Todavía poca información
Paralelismo y control
Uso de códigos correctores vs. replicación SF usa caché de “objetos” en nodo de cómputo Necesidad de coherencia en gestión de cachés
de coherencia
Más especialización Si “objeto” se extiende por varios dispositivos Necesidad de coherencia si se requiere actualización atómica

Solución basada en gestor de cerrojos distribuidos se trata de cerrojos internos del SF

Gestor de tokens (GT) único en sistema ejecutando en un NC Posible problema de escalabilidad y punto único de fallo

GeneralParallelFileSystemdeIBM Gestiona tokens lectura/escritura para distintos tipos de objetos Rangos

Control acceso paralelo a objeto

Doble rol del token
Gestor de cerrojos
control de caché del objeto
distribuidos
Operación en NC requiere token para cierto objeto Lo solicita a GT y lo mantiene

Solicitud múltiples tokens en una sola petición

Escalabilidad GT: minimizar su intervención NC que requiere token solicita directamente revocación a NCs

Nuevo fichero reutiliza inodo manteniendo tokens asociados al mismo

Protocolo basado en tokens asociados a rangos de bytes

1. Proceso lee/escribe fichero usando N llamadas: 1 único token

Optimización en la gestión de tokens
2. M proc. escriben fich. (1/M cada uno) con N llamadas/pr.: M tokens
Coherencia en acceso a datos
Rango requerido: el especificado en operación read/write
Solicitud de token incluye dos rangos:
Rango deseado: al que podría querer acceder en el futuro

Se revocan tokens que entran en conflicto con rango requerido

Resolución de solicitud:
Se concede rango deseado que no entre en conflicto

Si ningún otro cliente accede a F, no más peticiones de tokens.

Optimización en gestión de tokens En primera escritura/lectura a F, rango deseado [0,∞]
el proceso sólo pide un token

Directas (chmod)
Modificaciones concurrentes a metadatos de fichero
Indirectas: write -> fecha modificación, tamaño y punteros a bloques

Uso de token de acceso exclusivo por inodo no es eficiente Solicitud token de inodo por cada escritura aunque no solapadas
Coherencia acceso metadatos fichero
Idea actualización de inodo en paralelo y mezcla de cambios

token de escritura compartida y exclusiva

Solución
Ciertas ops. requieren token escritura exclusiva