The Google File System

Índice
 Introducción
 API
 Requisitos
 Arquitectura general
 Master
 Operaciones
 Recolección de basura
 Tolerancia a fallos
Introducción
 Se trata de un sistema de ficheros
distribuido y escalable.
 Requiere alto rendimiento para miles de
usuarios simultáneos.
 El sistema consta de miles de máquinas de
bajo coste (requiere tolerancia a fallos).
 Distinto a otros sistemas distribuidos, pero
igual en sus necesidades de escalabilidad,
rendimiento, fiabilidad, disponibilidad …
API
 No ofrece una API estándar como la API
POSIX pero los archivos están también
organizados jerárquicamente en directorios
e identificados por rutas.
 Cuenta con operaciones del tipo: create,
delete, open, close, read y write.
 Además existen las operaciones snapshot y
record append.
Requisitos
 Requiere tolerancia a fallos (miles de máquinas
de bajo coste).
 Se manejan ficheros de gran tamaño.
 Operaciones frecuentes:
 Lecturas secuenciales de gran tamaño (tipo streaming).
 Lecturas aleatorias de tamaño pequeño.
 Escrituras secuenciales grandes para añadir información
a ficheros (append).
 El sistema debe garantizar la coherencia de los
datos incluso con miles de usuarios accediendo
al mismo fichero.
Arquitectura general (I)
 Un cluster de GFS consta de:
 Un master.
 Varios chunkservers.
 Múltiples clientes.
 Cada fichero se divide en bloques de
64MB llamados chunk.
 Cada chunk cuenta normalmente con tres
réplicas para asegurar la coherencia de la
información.
Arquitectura general (II)
Master (I)
 Maneja los metadatos del sistema de
ficheros.
 Un único master simplifica el diseño, pero
debemos reducir al mínimo su participación
en las operaciones de lectura–escritura
(cuello de botella).
 Los clientes nunca deben leer y escribir
ficheros a través del master, sino que el
master les pondrá en contacto con el
chunkserver adecuado.
Master (II)
 El master maneja tres tipos de
metadatos:
 Espacio de nombre de los ficheros.
 Mapeo entre ficheros y chunks.
 La ubicación de cada fragmento de
réplica.
 Los metadatos se almacenan en
memoria.
 El master no guarda información
persistente acerca de los chunks.
 Operación de escritura (I)

1. El cliente solicita al master el chunkserver

que posee el contrato actual de un chunk y
las localizaciones la sus réplicas.
2. El master responde con la identidad de la
copia primaria y la ubicación de sus réplicas.
3. El cliente envía los datos a todas las
réplicas. Un cliente puede hacerlo en
cualquier orden. Los datos se escriben en un
buffer.
 Operación de escritura (II)
4. Cuando todas las réplicas han confirmado la
recepción de los datos, el cliente envía una
petición para escribir sobre la copia primaria. La
petición identifica los datos enviados inicialmente a
las réplicas. La copia primaria asigna números
consecutivos a las mutaciones que recibe. Aplica
las mutaciones en el orden que se ha establecido.
5. La primaria envía la petición de escritura a todas
las réplicas secundarias. Cada réplica aplica las
mutaciones en el mismo orden asignado por la
primaria.
Operación de escritura (III)

6. Todas las réplicas informan a la primaria

de que han completado la operación.
7. La primaria responde al cliente. Si se
produce un error se marcan las regiones
afectadas como inconsistentes y se
realizan varios intentos de repetir los
pasos 3 a 7 antes de repetir la operación
completa.
Operación de escritura (IV)
 Operaciones especiales
 Operación record append:
 Permite realizar escrituras simultáneas sobre un mismo
fichero.
 Operación snapshot:
 Operación para copiar de forma casi instantánea un
fichero o un árbol de directorios. Minimizando
cualquier interrupción de las mutaciones en curso.
 Recolección de basura

 La recolección de basura es llevada a cabo por el

master, en segundo plano: cuando se desea
borrar un fichero, se le marca. El master elimina
los ficheros marcados con tres días de
antigüedad.
 El sistema detecta también las réplicas que no
han sido actualizadas después de realizar
cambios en el original (fallos en un chunkserver).
 Para ello el master mantiene el número de versión de
los chunks, que es actualizado en las escrituras.
Tolerancia a fallos
 Recuperación rápida: tanto el master y como el
chunkserver permiten restaurar su estado y
reiniciarse en cuestión de segundos.
 Replicación de chunks: los chunks cuenta con
réplicas (normalmente tres).
 Replicación del estado del Master (para
garantizar fiabilidad): se almacena en disco, y
en caso de fallo, puede restituirse el estado
anterior.
 La integridad de datos se garantiza con
checksums.
Referencias
 Sanjay Ghemawat, Howard Gobioff, and Shun-Tak
Leung. “The Google File System”. 2003
http://labs.google.com/papers/gfs-sosp2003.pdf
 Entrada en Wikipedia:
http://en.wikipedia.org/wiki/Google_File_System