Google File System

De Wikipedia, la enciclopedia libre
Saltar a: navegación, búsqueda

No confundir con GMail File System

Google File System
Desarrollador
Google Inc
Información general
Última versión estable Colossus
Género Sistema de archivos distribuido
Sistema operativo Linux
Licencia Propietaria
Estado actual Activo
Versiones
? -> BigFiles -> Colossus
[editar datos en Wikidata ]

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 cluster de procesamiento en paralelo. La actual versión de Google File System tiene el nombre clave Colossus.[2]

El diseño[editar]

Google File System. Diseñado para interacción de sistema-a-sistema y no usuario-a-sistema. El conglomerado de servidores replica 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 cluster 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 clusteres 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 indentificació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[editar]

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).

Ver también[editar]

Referencias[editar]

  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 administar 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[editar]