Google File System

De Wikipedia, la enciclopedia libre
No debe confundirse con GMail File System.
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 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]​

En GFS, los datos se almacenan en múltiples servidores y se accede a ellos a través de una red de alta velocidad. El sistema utiliza una arquitectura maestro-esclavo, en la que un servidor principal (el maestro) coordina la actividad de varios servidores de datos (los esclavos).

El maestro mantiene un registro de la ubicación de los bloques de datos y garantiza que cada bloque se almacene en varios servidores para garantizar la redundancia y la tolerancia a fallas. También gestiona el proceso de lectura y escritura de archivos, asegurándose de que se realice de manera eficiente y confiable.

Los esclavos, por otro lado, son responsables de almacenar los bloques de datos y proporcionar acceso a ellos a través de una red. Cada esclavo tiene una cierta cantidad de espacio de almacenamiento y se encarga de manejar la replicación y distribución de los bloques de datos.

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

Cuando se aumenta el número de servidores de porciones en un clúster de Cassandra, además de mejorar la velocidad de lectura y el tiempo de respuesta, se obtienen otros beneficios significativos. Uno de ellos es la capacidad de escalar horizontalmente el clúster para manejar grandes volúmenes de datos y altas cargas de trabajo.

Al agregar más servidores de porciones, se distribuye la carga de trabajo entre ellos, lo que permite un mejor rendimiento general del sistema. Cada servidor de porciones es responsable de manejar una parte del conjunto de datos, lo que reduce la carga en cada nodo individual y mejora la capacidad de respuesta en situaciones de alta demanda.

Además, el aumento en el número de servidores de porciones permite un mayor almacenamiento de datos. Con múltiples servidores trabajando juntos, el clúster de Cassandra tiene la capacidad de almacenar grandes cantidades de información y escalar a medida que aumenta la cantidad de datos. Esto es particularmente valioso en entornos donde se generan y procesan grandes volúmenes de información en tiempo real, como aplicaciones de análisis de big data.

Otro beneficio importante de tener más servidores de porciones es la redundancia y la disponibilidad de datos. Con la replicación de datos en varios servidores, se garantiza que los datos estén protegidos contra fallos de hardware o interrupciones en un servidor en particular. Si uno de los servidores falla, los datos aún están disponibles en otras réplicas, lo que asegura la continuidad del servicio y evita la pérdida de información.

Véase 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 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[editar]

Obtenido de «https://es.wikipedia.org/w/index.php?title=Google_File_System&oldid=157809646»