Google File System
# Google File System

El Sistema de Archivos Google, en inglés Google File System (GFS, GooFS o GoogleFS), es un sistema de archivos distribuido propietario desarrollado por Google Inc, que soporta toda su infraestructura informática de procesamiento de información en nube. Está especialmente diseñado para proveer eficiencia, fiabilidad de acceso a datos usando sistemas masivos de clúster de procesamiento en paralelo. La actual versión de Google File System tiene el nombre clave Colossus.

En GFS, los datos se almacenan en múltiples servidores y se accede a ellos a través de una red de alta velocidad. El sistema utiliza una arquitectura maestro-esclavo, en la que un servidor principal (el maestro) coordina la actividad de varios servidores de datos (los esclavos).

El maestro mantiene un registro de la ubicación de los bloques de datos y garantiza que cada bloque se almacene en varios servidores para garantizar la redundancia y la tolerancia a fallas. También gestiona el proceso de lectura y escritura de archivos, asegurándose de que se realice de manera eficiente y confiable.

Los esclavos, por otro lado, son responsables de almacenar los bloques de datos y proporcionar acceso a ellos a través de una red. Cada esclavo tiene una cierta cantidad de espacio de almacenamiento y se encarga de manejar la replicación y distribución de los bloques de datos.

## El diseño

El GooFS es un sistema de archivos que está optimizado por Google para el almacenamiento de datos básicos y sus necesidades de uso (sobre todo el motor de búsqueda), y puede generar enormes cantidades de datos que deben ser mantenidas para optimizar la siguiente respuesta; El actual sistema de archivos surgió como una mejora a su BigFiles, desarrollado por Larry Page y Sergey Brin en los inicios de Google, cuando estudiaban en Stanford. Los archivos son divididos en porciones de tamaño fijo de 64 megabytes, similar a los clúster o sectores de las unidades de disco duro tradicional, donde muy rara vez son sobrescritos, o reducidos, por lo general los archivos se adicionan o se leen. También está diseñado y optimizado para funcionar con los clústeres de servidores de Google, nodos de alta concurrencia formado por computadoras de bajo coste, donde deben tomarse precauciones contra un alto índice de fallos por sobrecarga en los nodos individuales y por ende la probable pérdida de algunos datos. Otros puntos en el diseño apuntan a manejar una gran caudal de datos, e incluso resolución de problemas de latencia.

El cluster GooFS se compone de múltiples nodos. Estos se dividen en dos clases: un nodo Maestro y un gran número de almacenadores de fragmentos o Chunkservers. Los archivos se dividen en porciones de tamaño fijo, los Chunkservers almacenan las porciones, a cada porción se le asigna una etiqueta de identificación única de 64 bits en el nodo maestro al momento de ser creada, y el nodo Maestro conserva las asignaciones. A su vez cada porción es replicada en al menos tres servidores de una nube, pero así también existen archivos que requieren una mayor redundancia por su enorme demanda.

Los programas acceden a las porciones mediante consultas al nodo Maestro, para localizar la ubicación de los bloques deseados, si las porciones no se encuentran activas (por ejemplo, si no poseen accesos pendientes al almacenamiento), el nodo Maestro responde donde están ubicados, la aplicación contacta y recibe los datos desde el nodo de alojamiento directamente (es como el funcionamiento de las redes Kazaa, Skype y otros tipos de supernodos)

La principal diferencia entre los demás sistemas de archivos, es que el GooFS no está implementado en el kernel del sistema operativo, sino que funciona como una librería (biblioteca) en el espacio de usuario (userspace).

## Rendimiento

Para la decisión sobre su implementación debe hacerse un análisis bien enfocado sobre los resultados de su evaluación comparativa, pues cuando se utiliza con un número relativamente pequeño de servidores (cerca de 15), el sistema de archivos solo alcanza un rendimiento de lectura comparable a la de un solo disco clásico (80 a 100 MB/s), pero tiene un rendimiento de escritura bastante reducido (30 MB/s), y es relativamente lento (5 MB/s) para la acción de añadir los datos a los archivos existentes (los autores no presentan los resultados de tiempo de búsquedas aleatorias). Como el nodo Maestro no está directamente implicado en la lectura de los datos (los datos se transmiten desde el servidor de bloques directamente al cliente de lectura), la velocidad de lectura aumenta significativamente con el número de servidores de porciones, alcanzando 583 MB/s para 342 nodos. Al aumentar en un gran número los servidores también permite el aumento de velocidad del tiempo de respuesta, que también aumenta por el almacenamiento de copias de datos en tres servidores independientes (para proporcionar redundancia).

Cuando se aumenta el número de servidores de porciones en un clúster de Cassandra, además de mejorar la velocidad de lectura y el tiempo de respuesta, se obtienen otros beneficios significativos. Uno de ellos es la capacidad de escalar horizontalmente el clúster para manejar grandes volúmenes de datos y altas cargas de trabajo.

Al agregar más servidores de porciones, se distribuye la carga de trabajo entre ellos, lo que permite un mejor rendimiento general del sistema. Cada servidor de porciones es responsable de manejar una parte del conjunto de datos, lo que reduce la carga en cada nodo individual y mejora la capacidad de respuesta en situaciones de alta demanda.

Además, el aumento en el número de servidores de porciones permite un mayor almacenamiento de datos. Con múltiples servidores trabajando juntos, el clúster de Cassandra tiene la capacidad de almacenar grandes cantidades de información y escalar a medida que aumenta la cantidad de datos. Esto es particularmente valioso en entornos donde se generan y procesan grandes volúmenes de información en tiempo real, como aplicaciones de análisis de big data.

Otro beneficio importante de tener más servidores de porciones es la redundancia y la disponibilidad de datos. Con la replicación de datos en varios servidores, se garantiza que los datos estén protegidos contra fallos de hardware o interrupciones en un servidor en particular. Si uno de los servidores falla, los datos aún están disponibles en otras réplicas, lo que asegura la continuidad del servicio y evita la pérdida de información.

