El sistema de archivos de Google ( GFS o GoogleFS , que no debe confundirse con el sistema de archivos GFS Linux) es un sistema de archivos distribuido patentado desarrollado por Google para proporcionar un acceso eficiente y confiable a los datos utilizando grandes grupos de hardware básico . La última versión de Google File System con nombre en código Colossus se lanzó en 2010. [1] [2]
Sistema operativo | Kernel de Linux |
---|---|
Tipo | Sistema de archivos distribuido |
Licencia | Propiedad |
Diseño
GFS se ha mejorado para las necesidades básicas de almacenamiento y uso 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, mientras aún se encontraba 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 anexan 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 "básicas" baratas, lo que significa que se deben tomar precauciones contra la alta tasa de fallas de los nodos individuales y la subsiguiente pérdida de datos. Otras decisiones de diseño seleccionan para altos rendimientos de datos , incluso cuando se trata de un costo de latencia .
Un clúster de 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 servidores de trozos almacenan estos trozos. A cada fragmento se le asigna una etiqueta de 64 bits globalmente única por parte del nodo maestro en el momento de la creación, y se mantienen las asignaciones lógicas de los archivos a los fragmentos constituyentes. Cada fragmento se replica varias veces en toda la red. De forma predeterminada, se replica tres veces, pero es configurable. [3] 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 las políticas de limpieza rápida de basura. [3]
El servidor maestro no suele almacenar los fragmentos reales, sino todos los metadatos asociados con los fragmentos, como las tablas que mapean las etiquetas de 64 bits a las ubicaciones de los fragmentos y los archivos que componen (mapeo 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 (generalmente a instancias del servidor maestro, cuando, debido a fallas 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 por el servidor maestro que recibe periódicamente actualizaciones de cada servidor de fragmentos ("mensajes de latidos del corazón").
Los permisos para modificaciones son manejados por un sistema de "arrendamientos" por tiempo limitado, donde el servidor maestro otorga permiso a un proceso por un período de tiempo finito durante el cual el servidor maestro no otorgará permiso a ningún otro proceso para modificar el fragmento. . El chunkserver modificador, que siempre es el titular del fragmento principal, luego propaga los cambios a los chunkservers con las copias de seguridad. Los cambios no se guardan hasta que todos los chunkservers lo reconocen, 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 no se están operando los fragmentos (es decir, no existen arrendamientos pendientes), el Maestro responde con las ubicaciones, y el programa luego contacta y recibe los datos del chunkserver 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 kernel de un sistema operativo , sino que se proporciona como una biblioteca de espacio de usuario . [4]
Interfaz
El sistema de archivos de Google no proporciona una interfaz POSIX . [5] Los archivos se organizan jerárquicamente en directorios y se identifican por nombres de ruta. Se admiten las operaciones de archivo como crear, eliminar, abrir, cerrar, leer y escribir. Es compatible con Record Append, que permite que varios clientes agreguen datos al mismo archivo al mismo tiempo y se garantiza la atomicidad.
Actuación
A partir de los resultados de la evaluación comparativa, [3] 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) para agregar datos a archivos existentes. Los autores no presentan resultados sobre el tiempo de búsqueda aleatoria. Como el nodo principal no participa directamente en la lectura de datos (los datos se pasan del 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. La agregación de varios servidores también permite una gran capacidad, mientras que se reduce un poco al almacenar datos en tres ubicaciones independientes (para proporcionar redundancia).
Ver también
- Mesa grande
- Almacenamiento en la nube
- CloudStore
- Fossil , el sistema de archivos nativo de Plan 9
- Sistema de archivos paralelo general de GPFS IBM
- Sistema de archivos global 2 de GFS2 Red Hat
- Hadoop y su "Hadoop Distributed File System" (HDFS), un producto Java de código abierto similar a GFS
- Lista de productos de Google
- Mapa reducido
- MooseFS
- LizardFS
Referencias
- ↑ Hoff, Todd (11 de septiembre de 2010). "Coloso de Google hace búsqueda en tiempo real volcando MapReduce" . Alta escalabilidad . Archivado desde el original el 4 de abril de 2019.
- ^ Ma, Eric (29 de noviembre de 2012). "Coloso: sucesor del sistema de archivos de Google (GFS)" . SysTutorials. Archivado desde el original el 12 de abril de 2019 . Consultado el 10 de mayo de 2016 .
- ^ a b c Ghemawat, Gobioff y Leung 2003 .
- ^ Kyriazis, Dimosthenis (2013). Servicios de almacenamiento intensivo de datos para entornos de nube . IGI Global. pag. 13. ISBN 9781466639355.
- ^ Marshall Kirk McKusick; Sean Quinlan (agosto de 2009). "GFS: Evolución en avance rápido" . Cola de ACM . 7 (7): 10-20. doi : 10.1145 / 1594204.1594206 . Consultado el 21 de diciembre de 2019 .
Bibliografía
- Ghemawat, S .; Gobioff, H .; Leung, ST (2003). "El sistema de archivos de Google". Actas del XIX Simposio de ACM sobre principios de sistemas operativos - SOSP '03 (PDF) . pag. 29. CiteSeerX 10.1.1.125.789 . doi : 10.1145 / 945445.945450 . ISBN 1581137575. S2CID 221261373 .
enlaces externos
- "GFS: evolución en avance rápido", cola , ACM.
- "Evaluación del sistema de archivos de Google, Parte I", Mojo de almacenamiento.