Google File System

No debe confundirse con GMail 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.^[1]​ 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.^[2]​

Google File System
Información general
Tipo de programa	Sistema de archivos distribuido
Desarrollador	Google Inc
Descubridor	Howard Gobioff
Licencia	Propietaria
Estado actual	Activo
Versiones
Última versión estable	Colossus
Historial de versiones	? -> BigFiles -> Colossus
[editar datos en Wikidata]

El diseño

 

Google File System. Diseñado para interacción de sistema-a-sistema y no usuario-a-sistema. El conglomerado de servidores réplica la información automáticamente.

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;^[3]​ 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.^[4]​ Los archivos son divididos en porciones de tamaño fijo de 64 megabytes,^[5]​ 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,^[6]​ 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).

Véase también

• BigTable
• Cloud storage
• CloudStore
• Fossil, el sistema de archivos nativo de Plan 9.
• GFS
• GPFS General Parallel File System de IBM.
• Hadoop y su "Hadoop Distributed File System" (HDFS), un producto opensource en Java similar a GooFS.
• MapReduce

Referencias

1. "A pesar de que todos los detalles de la tecnología que implementa están disponibles, Google no ha liberado ningún código fuente, ni ha desarrollado software para libre uso público, la única manera de utilizarlo poder tener un acceso a esta implementación de alto rendimiento es convirtiéndose en cliente corporativo de Google Search Appliance, a través del cual Google alquila racks de servidores de cluster que implementan la tecnología."http://www.baselinemag.com/article2/0,1540,1985050,00.asp "How Google Works"]
2. High Scalability: Google's Colossus Makes Search Real-Time By Dumping MapReduce
3. "Todos estos análisis requieren una gran cantidad de espacio de almacenamiento. Cuando aún estudiaban en Stanford, solo el repositorio de documentos Web ocupaba 148 gigabytes, siendo luego reducido a 54 gigabytes mediante compresión de archivos, y el total de almacenamiento requierido, incluyendo los índices y la base de datos de enlaces, era de cerca de 109 gigabytes. Actualmente no aparenta ser demasiado, cuando incluso se hablan de unidades de disco para portátiles de 500 gigabytes como promedio, pero a finales de los 1990s los discos para PCs difícilmente superaban los 10 gigabytes." "How Google Works".
4. "Para hacer frente a estos requerimientos, Page y Brin desarrollaron un sistema de archivos virtual que administra los discos duros en varios equipos como un único sistema de almacenamiento. Lo llamaron BigFiles. En lugar los archivos se almacenen en un equipo determinado, se almacenan en BigFiles, este provee de una porción de espacio de almacenamiento en uno de los equipos del cluster de servidores y le asigna un equipo de administración, mientras guarda la lista de almacenamiento de los archivos de cada equipo. Esta es la base de lo que en esencia se convirtió en una infraestructura de software para computación distribuida que además corre sobre GNU/Linux." "How Google Works"
5. "Los archivos administrados típicamente por el sistema, van en el rango desde 100 megabytes a varios gigabytes. De esta manera, para administrar de eficientemente el espacio en disco, el GooFS organiza los datos en "porciones" de 64 megabytes, que son en sí análogos a los "bloques" en que se fragmenta un sistema en el archivos convencional para que la unidad de datos pueda ayudar a manejarla. En comparación, el tamaño típico del "bloque de datos" en Linux es de 4.096 bytes. Un ejemplo de esta comparación es la diferencia contener unos pocos bloques lo suficientemente grandes como para almacenar unas pocas páginas de texto, y contener varios estantes llenos enormes libros de varios volúmenes." "How Google Works"
6. Ghemawat Sanjay, Gobioff Howard, y Shun-Tak Leung. "El Sistema de Archivos Google"

Enlaces externos

• GFS: Evolution on Fast-forward
• Google File System Evaluación: Parte I at StorageMojo
• Cómo funciona Google?
• Grabaciones de un curso de Google sobre Sistemas Distribuidos, con algunas características y una lectura sobre GooFS
• ZDnet artículo sobre GooFS (enlace roto disponible en Internet Archive; véase el historial, la primera versión y la última).

•   Datos: Q1537683