A Comprehensive resume of Google File System (GFS) in Spanish

Si has llevado algún curso de Big Data (o si lo estás llevando actualmente), seguramente te ha tocado investigar acerca del sistema de archivos de Google que en síntesis no es más que un sistema de archivos distribuido que fue desarrollado por esta empresa para poder procesar una plétora de información de forma masiva y paralela con clusters.

El objetivo del sistema de archivos de Google (GFS) es la mejora en el rendimiento, escalabilidad, confiabilidad y disponibilidad del procesamiento de datos en la nube soportada por la infraestructura ad-hoc de Google.

Consideraciones Generales

La elaboración de este sistema implica tener que condicionan las particularidades propias del sistema:

1. Es de esperarse que se den fallas en el sistema y se deben considerar como la regla y no la excepción. A medida que el sistema crece, la probabilidad de que estos errores ocurran se incrementa dado que se tienen componentes de bajo costo y calidad como parte de la infraestructura tecnológica.
2. El sistema soporta archivos de gran tamaño.
3. Los archivos son creados (mutados) anexándose la data (appending) y no sobre-escribiendo los archivos ya creados.
4. El diseño conjunto de las aplicaciones y la API del sistema de archivos beneficia al sistema en general al aumentar la flexibilidad del mismo.

Descripción General del Diseño

El desarrollo del sistema de archivos parte de ciertos supuestos siendo los principales:

1. El sistema está construido sobre componentes de bajo costo (commodities).
2. El sistema almacena una cantidad considerable de archivos grandes (millones de archivos de alrededor de 100MB a más).
3. Un ancho de banda grande y sostenido es más importante que una baja latencia (se premia el procesamiento de datos en gran volumen a gran velocidad).

Arquitectura del GFS

Un cluster de GFS está compuesto por un solo Maestro y un vasto grupo de Chunkservers y es consultado por múltiples Clientes.

Imagen 1: Descripción gráfica de la arquitectura de un archivo bajo GFS, un archivo se divide en CHUNKS de 64MB siempre. Todos estos subarchivos son replicados (por default 3 veces). Cada CHUNKSERVER almacena estas replicas en un orden determinado por el MASTER . A su vez, el MASTER registra el CHECKPOINT IMAGE, la METADATA y el LOG. (Cortesía de pk.org)

Un aspecto importante que se debe tener en cuenta SIEMPRE es que los archivos se dividen en fragmentos(Chunks) de un tamaño fijo determinado y son almacenados en discos locales como archivos de Linux.

Un segundo aspecto sumamente importante, considerando que se trabaja sobre una infraestructura donde la regla es que falle, es el factor de replicación. Por defecto, se realizan 3 réplicas de los fragmentos que se almacenan en diferentes Chunkservers.

Supongamos que la temporada 8 de Game of Thrones pesa solo 192 MB. Lo que hacemos con el GFS es replicar el mismo archivo 3 veces y dividirlo en pequeños paquetes de no más de 64MB. Luego estos paquetes se agrupan en función a lo que mande el Maestro en los Chunkserver A, B y C. De este modo, si uno de los Chunkserver falla, puedes recuperar la información a partir de otro Chunkserver.

El Maestro se encarga de llevar a cabo una administración centralizada de la metadata:

• El nombre de cada trozo (Chunk) del archivo original.
• El control del acceso a la información.
• La asignación de los fragmentos.
• La ubicación de los fragmentos.

El Maestro

La ventaja de tener un solo Maestro radica en la simplicidad en la que esto permite tener un conocimiento global al momento de tomar decisiones de ubicación y replicación de los fragmentos.

Pero a su vez, tener un solo Maestro plantea un cuello de botella en situaciones en las que las consultas hacia un fragmento se vuelven masivas.

Para solucionar esta situación se tomaron medidas como establecer que los clientes no puedan leer ni escribir datos a través del Maestro. El cliente se limita a interactuar con el Maestro para consultar el Chunkserver que contiene la data que busca obteniendo utilizando el nombre del archivo y el índice donde se encuentra el fragmento que busca como una llave. Con esta información, el cliente contacta directamente al Chunkserver para las operaciones que requiera hasta que la información recibida del Maestro expire o el archivo sea reabierto.

Tamaño escogido para los trozos de archivos

Se decidió que el tamaño adecuado para cada fragmento era de 64MB. Esto representa ciertas ventajas:

1. Reduce la necesidad del cliente de interactuar con el Maestro.
2. Debido al tamaño del fragmento es más probable que un cliente realice una mayor cantidad de operaciones con dicho trozo reduciendo la sobrecarga de la red al mantener una conexión con el Chunkserver por un mayor periodo de tiempo.
3. Reduce el tamaño de la metadata que almacena el Maestro.

Sin embargo, también hay una ventaja que se debe mencionar:

1. Un archivo pequeño puede estar compuesto de algunos trozos o incluso solo 1 teniendo holgura en el espacio del trozo. Los Chunkservers que mantienen estos fragmentos pueden saturarse si muchos clientes acceden al mismo archivo. La forma en como se controla este aspecto es incrementar el factor de replicación y escalonando los tiempos de inicio de la aplicación.

Registro de operaciones (Operation Log)

Este registro contiene el histórico de los cambios en la metadata. Es el único registro persistente de metadata (es decir, se mantiene constantemente actualizado), a diferencia de la localización de los fragmentos que no se mantiene un histórico persistente (al momento de iniciar el Chunkserver y de manera periódica después).

El registro de operaciones sirve como una línea lógica de tiempo que establece el orden de las operaciones.

Consistencia del modelo

GFS es un modelo consistente que soporta aplicaciones altamente distribuidas mientras mantiene una relativa simplicidad y eficiencia en su implementación.

Los nombres de los fragmentos son “mutaciones” (creación de archivo) atómicas. Ahora, nos preguntaremos ¿Qué es una mutación? Pues la mutación es una operación que cambia el contenido o la metadata de un fragmento como una operación de escritura o de adición.

La región de un archivo es consistente si todos los clientes ven la misma data sin importar la réplica desde la que observan.

Cuando se habla de regiones se debe de diferenciar entre la región definida y la región no definida:

1. Cuando la mutación se da sin interferencia de escritores concurrentes, la región afectada se define y es consistente (todos los clientes verán lo que se ha escrito en la mutación).
2. En una mutación exitosa y concurrente, la región es consistente pero no está definida; es decir, los clientes verán la misma data pero no necesariamente esta refleja lo que otras mutaciones han escrito.
3. Una mutación fallida hace que la región afectada sea inconsistente (y no definida). Esto implica que diferentes clientes pueden ver diferente data en diferentes momentos.

Conclusiones generales

El GFS ha demostrado su capacidad para soportar el procesamiento de un caudal de datos de gran escala sobre una infraestructura de hardware de bajo costo.

Este sistema es tolerante a fallos debido a un monitoreo constante, replicación de datos y a la recuperación rápida y automática.

El sistema permite un alto rendimiento agregado para lectores y escritores concurrentes realizando una variedad de tareas. Esto se logra al separar el sistema de control de archivos que pasa a través del Maestro de la transferencia de datos que pasa directamente entre los Chunkservers y los clientes.

La participación del Maestro en las operaciones comunes se minimiza al tener fragmentos de 64 MB reduciendo la posibilidad de un cuello de botella.