Sistema de archivos de Google

Sistema de archivos de Google (GFS o GoogleFS, que no debe confundirse con el sistema de archivos GFS de Linux) es un sistema de archivos distribuido patentado desarrollado por Google para proporcionar acceso eficiente y confiable a los datos utilizando grandes grupos de hardware básico. El sistema de archivos de Google fue reemplazado por Colossus en 2010.

Diseño

GFS está mejorado para las necesidades principales de uso y almacenamiento de datos 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, cuando todavía estaba ubicado en Stanford. Los archivos se dividen en fragmentos de tamaño fijo de 64 megabytes, similares a los grupos o sectores de los sistemas de archivos normales, que rara vez se sobrescriben o reducen; 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 "productos básicos" baratos. ordenadores, lo que significa que se deben tomar precauciones contra la alta tasa de fallo de los nodos individuales y la consiguiente pérdida de datos. Otras decisiones de diseño optan por altos rendimientos de datos, incluso cuando se trata del costo de la latencia.

Un clúster GFS consta de varios nodos. Estos nodos se dividen en dos tipos: un nodo Master y múltiples Chunkservers. 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 global única de 64 bits en el momento de la creación, y se mantienen las asignaciones lógicas de archivos a los fragmentos constituyentes. Cada fragmento se replica varias veces en toda la red. De forma predeterminada, se replica tres veces, pero esto es configurable. Los archivos que tienen una gran demanda pueden tener un factor de replicación más alto, mientras que los archivos para los cuales el cliente de la aplicación utiliza optimizaciones de almacenamiento estrictas pueden replicarse menos de tres veces, para hacer frente a las políticas de limpieza rápida de basura.

El servidor maestro generalmente no almacena los fragmentos reales, sino todos los metadatos asociados con los fragmentos, como las tablas que asignan las etiquetas de 64 bits a las ubicaciones de los fragmentos y los archivos que los componen (asignación de archivos a fragmentos). , las ubicaciones de las copias de los fragmentos, qué procesos leen o escriben en un fragmento en particular o toman una "instantánea" del fragmento para replicarlo (generalmente a instancias del servidor maestro, cuando, debido a fallas del nodo, el número de copias de un fragmento ha caído por debajo del número establecido). Todos estos metadatos se mantienen actualizados mediante el servidor maestro que recibe periódicamente actualizaciones de cada servidor de fragmentos ("mensajes de latidos").

Los permisos para modificaciones se manejan mediante un sistema de "arrendamientos" de tiempo limitado y que vencen, donde el servidor maestro otorga permiso a un proceso por un período de tiempo finito durante el cual ningún otro proceso recibirá permiso. por el servidor maestro para modificar el fragmento. El servidor de fragmentos modificador, que siempre es el titular principal del fragmento, luego propaga los cambios a los servidores de fragmentos con las copias de seguridad. Los cambios no se guardan hasta que todos los servidores de fragmentos lo reconozcan, garantizando así 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 los fragmentos no están siendo operados (es decir, no existen arrendamientos pendientes), el Maestro responde con las ubicaciones y el programa luego contacta y recibe los datos del servidor de fragmentos directamente (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.

Interfaz

El sistema de archivos de Google no proporciona una interfaz POSIX. Los archivos se organizan jerárquicamente en directorios y se identifican por nombres de ruta. Se admiten operaciones de archivos 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.

Rendimiento

A partir de los resultados de las evaluaciones comparativas, cuando se utiliza con un número relativamente pequeño de servidores (15), el sistema de archivos logra 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 archivos existentes. Los autores no presentan resultados sobre el tiempo de búsqueda aleatoria. Como el nodo maestro no participa directamente en la lectura de datos (los datos se pasan desde el servidor de fragmentos directamente 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. Agregar múltiples servidores también permite una gran capacidad, aunque se reduce un poco al almacenar datos en tres ubicaciones independientes (para proporcionar redundancia).