Gfs GOOGLE FILE SYSTEM

GOOGLE FILE SYSTEM
(GFS)

INTRODUCCIÓN.

Google ha diseñado e implementado un Sistema distribuido de archivos escalable para dar soporte a los datos de sus aplicaciones. Diseñado por Sanjay Ghemawat, Howard Gobioff and Shun-Tak Leung de Google in 2002-03.

GFS prove TOLERANCIA A FALLAS, mientras corre en hardware económico de baja gama (Core 2 duo, de 2GB de ram con más de 800 GB de almacenamiento y un sistema operativo basado en Linux) todo esto porque al inicio de Google, no había recursos para comprar hardware de alta gama, también sirve a un gran número de clientes con un gran desempeño.

Al ser un sistema distribuido, GFS Comparte muchas de las características de los sistemas distribuidos anteriores (transparencias), impulsado por la gran carga y entornos únicos de Goolge. (el sistema operativo Android, que corresponde a Google, es el sistema operativo con más unidades a nivel mundial, sobrepasando a Windows, todas estas aplicaciones del SO ejecutan, en cierto modo un sistema distribuido).

El algoritmo base para la tecnología de búsqueda de Google es el algoritmo de Page Rank diseñado por Garry Brin y Larry Page en 1998.

Se debe dar a la idea que Google va más allá del campo de búsqueda, como email, maps, Google video, y el GFS soporta todas estas aplicaciones.

DESCRIPCIÓN GENERAL DEL DISEÑO.

SUPUESTOS:

 Al diseñar un sistema de archivos para las necesidades de Google, el desarrollo se ha guiado por supuestos que ofrecen tanto oportunidades como desafíos.

1. El sistema está construido a base de componentes económicos, que usualmente fallan, por esto debe estar constantemente monitoreándose y detectar, tolerar y recuperarse rápidamente de las fallas rutinariamente. “que un equipo falle no es una posibilidad es una ley”.
2. El sistema debe guardar un buen número de grandes archivos, por lo general unos cuantos millones de archivos típicamente de 100MB o un poco más, lo más común son los archivos multi-GB y estos deben ser manejados eficientemente, (OPTIMIZADOS).
3. Se poseen dos tipos de lecturas en la carga de trabajo:

1. En las lecturas de flujo grandes, las operaciones individuales suelen leer cientos de KB, más comúnmente 1 MB o más. Las operaciones sucesivas del mismo cliente suelen leerse a través de una región contigua de un archivo.
2. Una pequeña lectura aleatoria típicamente lee algunos KBs en algún desplazamiento arbitrario.

Las aplicaciones conscientes del rendimiento procesan por lotes y ordenan sus pequeñas búsquedas para avanzar constantemente a través del archivo en vez de ir y venir. 

1. Las cargas de trabajo también tienen muchas escrituras grandes y secuenciales que agregan datos a los archivos. Los tamaños de operación típicos son similares a los de las lecturas. Una vez escritos, los archivos rara vez se modifican de nuevo. Pequeñas escrituras en posiciones arbitrarias en un archivo son compatibles, pero no tienen que ser eficientes.

1. El sistema debe implementar una semántica bien definida para múltiples clientes que trabajan concurrentemente sobre el mismo archivo. La atomicidad en la sincronización es esencial.

1. La sustentación de un gran ancho de banda es más importante que una baja latencia. 

ARQUITECTURA

 Un clúster GFS consiste en un MAESTRO y múltiples CHUNKSERVERS y es accedido por múltiples clientes. La analogía básica de GFS es el Master mantiene los metadatos; el cliente contacta al  master y recupera los metadatos sobre los CHUNKS que están guardados en los chunkservers; después el cliente contacta directamente los chunksertvers.

[pic 1]

Cada uno de estos típicamente es una maquina Linux económica corriendo un servidor de proceso de nivel de usuario. Los archivos son divididos en un tamaño fijo (Chunks), cada chunk está identificado por 64 bits inmutables y globalmente únicos llamado Chunk handle asignado por el maestro en el momento de la creación del chunk. Chunkservers guardan chunk en discos locales como archivos linuz y leen o escriben datos chunk especificado  por un chunk hndle y un byte de rango, por relatividad, cada chunk es replicado en multiples chunkservers, por defecto tres copias son guardadas. El maestro mantiene todos archivos de la metadata del sistema, estas incluyen nombre, información del control de acceso, el mapeo desde los archivos a los chunks y la locación de los chunks. También el master se comunica periódicamente con los chunkservers y recolecta sus estados.

El cliente interactúa con el maestro para operaciones de la metadata, pero toda la comunicación con la información va directamente  a los chunkservers

CHUNK

Chunk en GFS es una decisión de diseño muy importante. Es similar a el concepto de bloque en sistemas de archivos, pero mucho más grande que el tamaño típico de los bloques, comparados con generalmente algunos KB de tamaño de los sistemas de archivos, el tamaño de los chunks son 64MB. Este diseño fue para ayudar en el entorno único de Google. (recordar que en Google nada es pequeño y que trabaja con TBs y archivos de multiples GBs)

cada chunk está identificado por 64 bits inmutables y globalmente únicos llamado Chunk handle asignado por el maestro en el momento de la creación del chunk.

Por relatividad, cada chunk es replicado en multiples chunkservers, por defecto tres copias son guardadas

Algunos beneficios de esto son:

• No necesita contactar al maestro muchas veces. Reduce la carga del master ya que con un solo contacto se puede conseguir mucha información.
• Reduce el tamaño de la metadata en el master.
• No hay fragmentación interna debido a “la asignación de espacio perezoso”

Un problema probable de este tamaño de chunk fue que algún pequeño archivo  podría pesar algunos KB  siendo menor que el tamaño del chunk (64 MB) este puede ser accedido muchas veces, creando un hotspot, la solución a este problema fue que dichos archivos fueran guardados con un alto factor de replicación.

...