Google File System ( GFS o GoogleFS , que no debe confundirse con el sistema de archivos GFS de Linux) es un sistema de archivos distribuido propietario desarrollado por Google para proporcionar un acceso eficiente y confiable a los datos mediante grandes grupos de hardware de consumo . El sistema de archivos de Google fue reemplazado por Colossus en 2010. [1]
GFS está optimizado para las necesidades de almacenamiento y uso de datos básicos de Google (principalmente el motor de búsqueda ), que puede generar enormes cantidades de datos que deben conservarse; Google File System surgió de un esfuerzo anterior de Google, "BigFiles", desarrollado por Larry Page y Sergey Brin en los primeros días de Google, mientras aún estaba ubicado en Stanford . Los archivos se dividen en fragmentos de tamaño fijo de 64 megabytes , similares a los clústeres o sectores en los sistemas de archivos regulares, que solo se sobrescriben o reducen en muy raras ocasiones; los archivos generalmente se agregan o se leen. También está diseñado y optimizado para ejecutarse en los clústeres informáticos de Google, nodos densos que consisten en computadoras "comerciales" baratas, lo que significa que se deben tomar precauciones contra la alta tasa de fallas de los nodos individuales y la posterior pérdida de datos. Otras decisiones de diseño seleccionan altos rendimientos de datos , incluso cuando se produce a costa de la latencia .
Un clúster GFS consta de varios nodos. Estos nodos se dividen en dos tipos: un nodo maestro y varios servidores de fragmentos . Cada archivo se divide en fragmentos de tamaño fijo. Los servidores de fragmentos almacenan estos fragmentos. El nodo maestro asigna a cada fragmento una etiqueta de 64 bits única a nivel global en el momento de la creación, y se mantienen las asignaciones lógicas de los archivos a los fragmentos que los constituyen. Cada fragmento se replica varias veces en toda la red. De forma predeterminada, se replica tres veces, pero esto es configurable. [2] Los archivos que tienen una gran demanda pueden tener un factor de replicación más alto, mientras que los archivos para los que el cliente de la aplicación utiliza optimizaciones de almacenamiento estrictas pueden replicarse menos de tres veces, para hacer frente a políticas de limpieza rápida de basura. [2]
El servidor maestro no suele almacenar los fragmentos reales, sino todos los metadatos asociados a los fragmentos, como las tablas que asignan las etiquetas de 64 bits a las ubicaciones de los fragmentos y los archivos que forman (asignación de archivos a fragmentos), las ubicaciones de las copias de los fragmentos, qué procesos están leyendo o escribiendo en un fragmento en particular, o tomando una "instantánea" del fragmento para replicarlo (normalmente a instancias del servidor maestro, cuando, debido a fallos de nodos, el número de copias de un fragmento ha caído por debajo del número establecido). Todos estos metadatos se mantienen actualizados gracias al servidor maestro, que recibe periódicamente actualizaciones de cada servidor de fragmentos ("mensajes de latido").
Los permisos para realizar modificaciones se gestionan mediante un sistema de "concesiones" con límite de tiempo y vencimiento, en el que el servidor maestro concede permiso a un proceso durante un período finito durante el cual ningún otro proceso recibirá permiso del servidor maestro para modificar el fragmento. El servidor de fragmentos que realiza la modificación, que siempre es el principal poseedor del fragmento, propaga entonces los cambios a los servidores de fragmentos con las copias de seguridad. Los cambios no se guardan hasta que todos los servidores de fragmentos los reconocen, lo que garantiza la finalización y atomicidad de la operación.
Los programas acceden a los fragmentos consultando primero al servidor maestro las ubicaciones de los fragmentos deseados; si no se está operando en los fragmentos (es decir, no existen arrendamientos pendientes), el maestro responde con las ubicaciones y luego el programa se comunica y recibe los datos directamente del servidor de fragmentos (similar a Kazaa y sus supernodos ).
A diferencia de la mayoría de los otros sistemas de archivos, GFS no se implementa en el núcleo de un sistema operativo , sino que se proporciona como una biblioteca de espacio de usuario . [3]
El sistema de archivos de Google no proporciona una interfaz POSIX . [4] Los archivos se organizan jerárquicamente en directorios y se identifican por rutas de acceso. Se admiten operaciones de archivo como crear, eliminar, abrir, cerrar, leer y escribir. Admite Record Append, que permite que varios clientes agreguen datos al mismo archivo simultáneamente y se garantiza la atomicidad.
A partir de los resultados de evaluación comparativa [2] , cuando se utiliza con un número relativamente pequeño de servidores (15), el sistema de archivos alcanza un rendimiento de lectura comparable al de un solo disco (80–100 MB/s), pero tiene un rendimiento de escritura reducido (30 MB/s) y es relativamente lento (5 MB/s) al agregar datos a los archivos existentes. Los autores no presentan resultados sobre el tiempo de búsqueda aleatorio. Como el nodo maestro no está directamente involucrado en la lectura de datos (los datos se pasan directamente del servidor de fragmentos al cliente de lectura), la velocidad de lectura aumenta significativamente con el número de servidores de fragmentos, alcanzando 583 MB/s para 342 nodos. La agregación de múltiples servidores también permite una gran capacidad, mientras que se reduce un poco al almacenar datos en tres ubicaciones independientes (para proporcionar redundancia).