Sistema de archivos de Google

El 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 propietario desarrollado por Google para proporcionar acceso eficiente y fiable a los datos mediante grandes clústeres de hardware estándar . 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 principales de Google (principalmente el motor de búsqueda ), que puede generar enormes cantidades de datos que deben conservarse; Google File System surgió de un proyecto anterior de Google, "BigFiles", desarrollado por Larry Page y Sergey Brin en los inicios de Google, cuando aún se encontraba en Stanford . Los archivos se dividen en bloques de tamaño fijo de 64 megabytes , similares a los clústeres o sectores en los sistemas de archivos regulares, que rara vez se sobrescriben o reducen; los archivos generalmente se añaden o se leen. También está diseñado y optimizado para ejecutarse en los clústeres de computación de Google, nodos densos que consisten en computadoras "comerciales" económicas, lo que significa que se deben tomar precauciones contra la alta tasa de fallas de los nodos individuales y la consiguiente pérdida de datos. Otras decisiones de diseño priorizan un alto rendimiento de datos , incluso cuando esto conlleva un aumento de la latencia .

Un clúster GFS consta de varios nodos. Estos nodos se dividen en dos tipos: un nodo maestro y varios Chunkservers . Cada archivo se divide en fragmentos de tamaño fijo. Los Chunkservers almacenan estos fragmentos. El nodo maestro asigna a cada fragmento una etiqueta globalmente única de 64 bits en el momento de su 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. Por defecto, se replica tres veces, pero esto es configurable. ^{[ 2 ]} Los archivos con alta demanda pueden tener un factor de replicación mayor, 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 de basura rápidas. ^{[ 2 ]}

El servidor maestro no suele almacenar los fragmentos propiamente dichos, sino todos los metadatos asociados a ellos, como las tablas que relacionan las etiquetas de 64 bits con las ubicaciones de los fragmentos y los archivos que los componen (mapeo de archivos a fragmentos), las ubicaciones de las copias de los fragmentos, los procesos que leen o escriben en un fragmento en particular, o que toman una "instantánea" del fragmento para replicarlo (normalmente a instancias del servidor maestro, cuando, debido a fallos en los 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 a que el servidor maestro recibe periódicamente actualizaciones de cada servidor de fragmentos ("mensajes de latido").

Los permisos de modificación se gestionan mediante un sistema de "arrendamientos" temporales, donde el servidor maestro otorga permiso a un proceso durante un período determinado, durante el cual ningún otro proceso recibirá permiso del servidor maestro para modificar el fragmento. El servidor de fragmentos modificador, que siempre es el poseedor principal del fragmento, propaga los cambios a los servidores de fragmentos que contienen las copias de seguridad. Los cambios no se guardan hasta que todos los servidores de fragmentos los confirman, lo que garantiza la finalización y la atomicidad de la operación.

Los programas acceden a los fragmentos consultando primero al servidor maestro para obtener las ubicaciones de los fragmentos deseados; si no se está operando con los fragmentos (es decir, no existen concesiones pendientes), el maestro responde con las ubicaciones y el programa luego se comunica y recibe los datos directamente del servidor de fragmentos (de forma similar a Kazaa y sus supernodos ).

A diferencia de la mayoría de los demás sistemas de archivos, GFS no está implementado 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 mediante rutas de acceso. Se admiten operaciones de archivo como crear, eliminar, abrir, cerrar, leer y escribir. Admite la función Record Append, que permite que varios clientes agreguen datos al mismo archivo simultáneamente, garantizando la atomicidad.

A partir de los resultados de las pruebas comparativas, ^{[ 2 ]} 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 del servidor de fragmentos directamente al cliente de lectura), la tasa 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, aunque se reduce un poco al almacenar datos en tres ubicaciones independientes (para proporcionar redundancia).

• Mesa grande
• Almacenamiento en la nube
• CloudStore
• Fossil , el sistema de archivos nativo de Plan 9
• GPFS ( Sistema General de Archivos Paralelos) de IBM
• GFS2 Sistema de archivos global 2 de Red Hat
• Apache Hadoop y su "Sistema de Archivos Distribuidos de Hadoop" (HDFS), un producto Java de código abierto similar a GFS.
• Lista de productos de Google
• MapReduce
• Sistema de archivos Moose
• LagartoFS

• "GFS: Evolución a toda velocidad", Queue , ACM.
• "Evaluación del sistema de archivos de Google, parte I", Storage mojo.